Perhaps I'm just missing something simple so here goes.
I have a webmin server on Ubuntu and also OpenGTS on a vps, everything works fine and I set it all up from scratch.
I have a cron job like this:
bash /usr/local/OpenGTS_2.5.0/bin/trim.sh
trim.sh is:
#!/bin/sh
MAILTO=me#mymail.net
cd /usr/local/OpenGTS_2.5.0/bin/
./admin.sh Device -account=vehicles -device=laguna -deleteOldEvents=-5d -confirmDelete
This should delete old entries from the database older than 5 days
When run from command line it outputs correctly
Entry Point: org.opengts.db.tables.Device
Deleting events before "Wed Jun 11 23:59:59 BST 2014" ...
Device: laguna - Deleted 0 old events (Saved last event, Nothing to delete)
However when it runs from cron
Entry Point: org.opengts.db.tables.Device
Deleting events before "Mon Jun 09 23:59:59 BST 2014" ...
Device: laguna - Deleted 0 old events (Empty range)
If I set it to 1 day, or 2 days it still insists on Mon Jun 09 23:59:59 BST 2014
I'm totally stumped, any ideas ?
thanks
Related
I want to write a shell script sort out the data that last command shows.
I got this in my server.
root pts/0 10.168.136.175 Wed Sep 14 14:24 - 14:54 (00:29)
root :0 Mon Sep 12 10:34 - 11:00 (00:25)
reboot system boot 2.6.18-308.el5PA Sun Sep 11 11:31 (86+03:05)
I did some search, there are some saying :0.0 in the 3rd column means login locally, second column means what kind of terminal been use, like pts and tty.
But what does the :0 in line 2 second column in my log?
I am using redhat 6.5.
It means local computer. Generally each session represented by pairs ip_address:display_number. When you logged in locally the IP address is omitted. That's why there is nothing before :. Display number is actually the session number from the specified IP address. So, 0 means the first session
Suddenly the hourly cron job on openshift stopped working.
I am using a free account and the cron was running fine until suddenly it just stopped working.
Minutely jobs on the other hand are running fine, given the following files
app-root/runtime/repo/.openshift/cron/minutely/cminut
#!/bin/bash
echo 'ping'
and
app-root/runtime/repo/.openshift/cron/hourly/chour
#!/bin/bash
echo 'pong'
as well as the following permissions
[xxx-xxxxxxx.rhcloud.com cron]\> ls -la hourly/
total 4
drwx------. 2 1234567 1234567 18 Jun 28 19:04 .
drwx------. 4 1234567 1234567 52 Jun 28 19:04 ..
-rwx--x--x. 1 1234567 1234567 24 Jun 28 19:04 chour
[xxx-xxxxxxx.rhcloud.com cron]\> ls -la minutely/
total 4
drwx------. 2 1234567 1234567 19 Jun 28 19:04 .
drwx------. 4 1234567 1234567 52 Jun 28 19:04 ..
-rwx------. 1 1234567 1234567 24 Jun 28 19:04 cminut
[xxx-xxxxxxx.rhcloud.com cron]\>
The minutely cron job runs fine and i can see the log file cron_minutely.log in $OPENSHIFT_LOG_DIR
For the hourly cron job i can not see the cron_hourly.log neither the job is executed
My previous attempts wen't trough uninstalling and re installing the cron cartridge as mentioned here but there was no success running the hourly cron job.
Is there any other way that i can debug this, or any openshift specific fix known in order to solve this?
After some desperate attempts and inspecting the cron job cartridge script cron_runjobs.sh
i came to note that whenever i runed the hourly cron via this script the log
":SKIPPED: $freq cron run for openshift user '$OPENSHIFT_GEAR_UUID"
popped up, such message was not fired for other crons (minutely, weekly...)
upon closer inspection i noticed that there were several processes with this script cron_runjobs.sh running on the server, after killing this processes and re-deploying the application the hourly cron job started again to work as expected.
I do not know why were these processes hanged and still running, maybe because i used sleep in the hourly cron before, although not sure if that was the reason.
I was writing perl and run it in window system pretty good .
But when i transfer the perl script from windows system to Linux.
And run in Linux system , i get wrong date/time.
Need some help. Thanks.
The source code in Perl
if (($file =~ m/(\d)(\S+)\.csv/) && ($flag == 0))
{
open(para_file,$file);
$datetime_string = ctime( stat($file)->ctime );
while ($line=<para_file>)
{
if ($line =~ /0\,170\,16\,/)
{
$cal = $cal + 1;
}
}
push(#data,"$cal");
push(#data,"$datetime_string");
}
$file will be my file name. The windows date & time on create are correct but don't understand why in LINUX it give me the wrong date & time.
Output of generation , from windows
9023-0 50000 5111 10.22 Mon Jul 21 17:44:38 2014
9023-2 100000 23251 23.25 Fri Apr 11 10:12:19 2014
9024_AHG 5000 0 0.00 Thu Nov 27 15:28:55 2014
Output of generation , from linux
9023-0 50000 5111 10.22 Thu Jul 30 16:45:25 2015
9023-2 100000 23251 23.25 Thu Jul 30 16:45:25 2015
9024_AHG 5000 0 0.00 Thu Jul 30 16:45:25 2015
The problem here isn't what you're doing, it's that you misunderstand what ctime is. Linux filesystems record a change time not a creation time.
mtime denotes modification of file content. ctime denotes modification of attributes. As a result, they may well be the same number.
However what you cannot get is "create time" because the EXT filesystem doesn't record it. (Other filesystem formats may - NTFS for example - but I'm not sure I'd suggest using NTFS on a Linux box!)
I'm getting two different timezones on Linux (CENTOS 5.6) depending on whether date is called locally or via ssh:
foo$ ssh me#bar date
Tue Nov 5 18:08:32 EST 2013
foo$ ssh me#bar
bar$ date
Tue Nov 5 17:09:16 CST 2013
/etc/localtime is set to central time:
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 27 Nov 5 13:10 /etc/localtime -> /usr/share/zoneinfo/CST6CDT
TZ is set to America/Chicago in .bash_profile. If that line is commented out, time zone comes back as eastern rather than central.
I'm assuming this all means the computer believes in its heart that it's on eastern rather than central time and the TZ setting in the shell just overrides this, but I can't figure out WHY the computer thinks it's in eastern time.
edit
It turned out that a runaway process somewhere had actually overwritten the central time timezone file with an eastern time timezone file. Not easy to find, as the file contents are binary!
Did you check -> /etc/sysconfig/clock ?
I'm running rdiff-backup to backup some folders on a remote system.
rdiff-backup root#<REMOTESERVER>::/apps/myapp/shared/system /home/backups/system
echo "$(date): Completed... removing backup data older than 4 weeks"
rdiff-backup --remove-older-than 4W /home/backups/system
echo "$(date): Completed..."
Running this leads to errors though during the --remove-older-than command:
Fatal Error: Found 81 relevant increments, dated:
Wed Aug 29 00:41:47 2012
Thu Aug 30 00:57:49 2012
Fri Aug 31 01:04:03 2012
Sat Sep 1 00:44:59 2012
Sun Sep 2 00:41:49 2012
Mon Sep 3 00:41:39 2012
If you want to delete multiple increments in this way, use the --force.
So yeah, I can probably just put --force on it, but I'd like to understand what's going on here and haven't been able to find much on this problem.
Any ideas?
It's just rdiff-backup making sure you really mean it. The usual workflow for --remove-older-than is to run regularly, removing just the oldest increment. In order to avoid data-loss, rdiff-backup requires you to be really sure before letting you remove multiple increments at once.