Mysterious cron problem with Suse 9.3
Hi all, I'm running Suse Linux 9.3, and I'm having problems with cron not actually running cron jobs. I suspect this is the kind of profile issue that commonly happens with cron jobs, but I don't have any idea how to debug it. For example, if as root, I run crontab -e and enter the following very simple cron job: 22 12 * * * /usr/bin/touch /root/hello.root In /var/log/messages, I have the following output: Dec 2 12:21:23 hypervisor1 crontab[7015]: (root) BEGIN EDIT (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) REPLACE (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) END EDIT (root) Dec 2 12:22:01 hypervisor1 /usr/sbin/cron[6536]: (root) RELOAD (tabs/root) so it sure seems like cron is waking up, finding the job, and then going back to sleep. However, the file that should be touch-ed is not there, and there are no error messages, either in /var/log/messages or as an email. Can anyone give me advice on how to debug this problem, or why cron does not appear to be actually running the job? Thanks, Eric
On Friday 02 December 2005 01:22 pm, Eric E wrote:
Hi all, I'm running Suse Linux 9.3, and I'm having problems with cron not actually running cron jobs. I suspect this is the kind of profile issue that commonly happens with cron jobs, but I don't have any idea how to debug it.
For example, if as root, I run crontab -e and enter the following very simple cron job:
22 12 * * * /usr/bin/touch /root/hello.root
In /var/log/messages, I have the following output:
Dec 2 12:21:23 hypervisor1 crontab[7015]: (root) BEGIN EDIT (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) REPLACE (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) END EDIT (root) Dec 2 12:22:01 hypervisor1 /usr/sbin/cron[6536]: (root) RELOAD (tabs/root)
so it sure seems like cron is waking up, finding the job, and then going back to sleep. However, the file that should be touch-ed is not there, and there are no error messages, either in /var/log/messages or as an email.
Can anyone give me advice on how to debug this problem, or why cron does not appear to be actually running the job?
Thanks,
Eric
Well for starters, I looked in /var/log/messages and all of the cron jobs I run in the same manner have log entries that look like the below: Nov 27 22:10:01 linux1 /usr/sbin/cron[15239]: (root) CMD (/usr/local/bin/putwx) Notice the CMD that follows the userid.... Yours shows RELOAD which to me indicates that the RELOAD was due to your changing the crontab, and did not have anything to do with running the command. (cron is reloading the file) Was there any log message after the above? Perhaps you just missed it on the timing.... I tried the same thing here, with a few minutes to lapse first, and it worked fine. (and it did the reload on the next minute after I ran crontab -e.
On Fri, 2005-12-02 at 13:22 -0500, Eric E wrote:
Hi all, I'm running Suse Linux 9.3, and I'm having problems with cron not actually running cron jobs. I suspect this is the kind of profile issue that commonly happens with cron jobs, but I don't have any idea how to debug it.
For example, if as root, I run crontab -e and enter the following very simple cron job:
22 12 * * * /usr/bin/touch /root/hello.root
In /var/log/messages, I have the following output:
Dec 2 12:21:23 hypervisor1 crontab[7015]: (root) BEGIN EDIT (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) REPLACE (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) END EDIT (root) Dec 2 12:22:01 hypervisor1 /usr/sbin/cron[6536]: (root) RELOAD (tabs/root)
so it sure seems like cron is waking up, finding the job, and then going back to sleep. However, the file that should be touch-ed is not there, and there are no error messages, either in /var/log/messages or as an email.
Can anyone give me advice on how to debug this problem, or why cron does not appear to be actually running the job?
Thanks,
Eric
The touch command is in /bin not /usr/bin. To verify use which touch to find where it is on your system. On my 9.3 system it is under /bin. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
On Fri, 2005-12-02 at 13:40 -0500, Ken Schneider wrote:
On Fri, 2005-12-02 at 13:22 -0500, Eric E wrote:
Hi all, I'm running Suse Linux 9.3, and I'm having problems with cron not actually running cron jobs. I suspect this is the kind of profile issue that commonly happens with cron jobs, but I don't have any idea how to debug it.
For example, if as root, I run crontab -e and enter the following very simple cron job:
22 12 * * * /usr/bin/touch /root/hello.root
In /var/log/messages, I have the following output:
Dec 2 12:21:23 hypervisor1 crontab[7015]: (root) BEGIN EDIT (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) REPLACE (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) END EDIT (root) Dec 2 12:22:01 hypervisor1 /usr/sbin/cron[6536]: (root) RELOAD (tabs/root)
so it sure seems like cron is waking up, finding the job, and then going back to sleep. However, the file that should be touch-ed is not there, and there are no error messages, either in /var/log/messages or as an email.
Can anyone give me advice on how to debug this problem, or why cron does not appear to be actually running the job?
Thanks,
Eric
The touch command is in /bin not /usr/bin. To verify use which touch to find where it is on your system. On my 9.3 system it is under /bin.
Correction. There is also a link in /usr/bin. Sorry. But I will agree with Bruce that you set the time to run to close to the clock time. Try setting it 2-3 minutes in the future to test. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Funny, I got the advice to use /usr/bin/touch from IRC... Anyway, it seems to be in both on my machine: # which touch /usr/bin/touch # ls /bin/touch /bin/touch Ken Schneider wrote:
On Fri, 2005-12-02 at 13:22 -0500, Eric E wrote:
Hi all, I'm running Suse Linux 9.3, and I'm having problems with cron not actually running cron jobs. I suspect this is the kind of profile issue that commonly happens with cron jobs, but I don't have any idea how to debug it.
For example, if as root, I run crontab -e and enter the following very simple cron job:
22 12 * * * /usr/bin/touch /root/hello.root
In /var/log/messages, I have the following output:
Dec 2 12:21:23 hypervisor1 crontab[7015]: (root) BEGIN EDIT (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) REPLACE (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) END EDIT (root) Dec 2 12:22:01 hypervisor1 /usr/sbin/cron[6536]: (root) RELOAD (tabs/root)
so it sure seems like cron is waking up, finding the job, and then going back to sleep. However, the file that should be touch-ed is not there, and there are no error messages, either in /var/log/messages or as an email.
Can anyone give me advice on how to debug this problem, or why cron does not appear to be actually running the job?
Thanks,
Eric
The touch command is in /bin not /usr/bin. To verify use which touch to find where it is on your system. On my 9.3 system it is under /bin.
Eric, On Friday 02 December 2005 12:28, Eric E wrote:
Funny, I got the advice to use /usr/bin/touch from IRC... Anyway, it seems to be in both on my machine:
# which touch /usr/bin/touch
# ls /bin/touch /bin/touch
It goes all the way back to the dim dark mists of time. At least to Bell Labs v7 Unix. To wit: % rpm -q --whatprovides /bin/touch /usr/bin/touch coreutils-5.3.0-20 coreutils-5.3.0-20 It's probably in both places (/usr/bin/touch is a symlink on my system) because over time different versions of Unix (-like operating systems) have put it in different places and having both just prevents a lot of things from breaking. And check out the man page. You can, e.g., control the actual timestamp used, overriding the default which is the time of invocation. Randall Schulz
Randall R Schulz wrote:
Eric,
On Friday 02 December 2005 12:28, Eric E wrote:
Funny, I got the advice to use /usr/bin/touch from IRC... Anyway, it seems to be in both on my machine:
# which touch /usr/bin/touch
# ls /bin/touch /bin/touch
It goes all the way back to the dim dark mists of time. At least to Bell Labs v7 Unix. To wit:
% rpm -q --whatprovides /bin/touch /usr/bin/touch coreutils-5.3.0-20 coreutils-5.3.0-20
It's probably in both places (/usr/bin/touch is a symlink on my system) because over time different versions of Unix (-like operating systems) have put it in different places and having both just prevents a lot of things from breaking.
LSB require all tools required to repair filesystems and mount /usr (which might not be available at boot time) be in /bin, /lib etc. This clearly requires touch (in initialisation scripts): summer@Phascogale:~> ls -l /usr/bin/touch /bin/touch -rwxr-xr-x 1 root root 34276 2005-09-10 13:56 /bin/touch lrwxrwxrwx 1 root root 10 2005-11-26 19:58 /usr/bin/touch -> /bin/touch summer@Phascogale:~> ssh bilby ls -l /usr/bin/touch /bin/touch summer@bilby's password: ls: /usr/bin/touch: No such file or directory -rwxr-xr-x 1 root root 40842 Mar 24 2005 /bin/touch summer@Phascogale:~> ssh gw ls -l /usr/bin/touch /bin/touch Password: -rwxr-xr-x 1 root root 30360 Jul 16 2004 /bin/touch lrwxrwxrwx 1 root root 10 Nov 21 2004 /usr/bin/touch -> /bin/touch summer@Phascogale:~> ssh ns ls -l /usr/bin/touch /bin/touch summer@ns's password: ls: /usr/bin/touch: No such file or directory -rwxr-xr-x 1 root root 31932 Apr 28 2005 /bin/touch summer@Phascogale:~> Ihave some diversity hee:-) gw is Debian/Sarge ns is WBEL Bilby was Fedora Core 3, is overlaid with much self-built RHEL 4. Phascogale is SUSE 10. Oh, and here is OS X summer@Phascogale:~> ssh bilby ssh eagle ls -l /usr/bin/touch /bin/touch summer@bilby's password: ls: /bin/touch: No such file or directory -r-xr-xr-x 1 root wheel 18496 Mar 22 2005 /usr/bin/touch summer@Phascogale:~>
On Friday 02 December 2005 01:40 pm, Ken Schneider wrote:
The touch command is in /bin not /usr/bin. To verify use which touch to find where it is on your system. On my 9.3 system it is under /bin.
I have touch in both /bin and /usr/bin
At 01:22 PM 12/2/05, Eric E wrote:
Hi all, I'm running Suse Linux 9.3, and I'm having problems with cron not actually running cron jobs. I suspect this is the kind of profile issue that commonly happens with cron jobs, but I don't have any idea how to debug it.
For example, if as root, I run crontab -e and enter the following very simple cron job:
22 12 * * * /usr/bin/touch /root/hello.root
In /var/log/messages, I have the following output:
Dec 2 12:21:23 hypervisor1 crontab[7015]: (root) BEGIN EDIT (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) REPLACE (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) END EDIT (root) Dec 2 12:22:01 hypervisor1 /usr/sbin/cron[6536]: (root) RELOAD (tabs/root)
Nothing mysterious about it. It alsways works that way. The time is too close to current time. If you want something to run at 12:22, then you must make the change to crontab before 12:21. cron cannot RELOAD at 12:22 *and* execute a task at 12:22 that wasn't there at 12:21. That's the way it works on every Linux and *bsd system I've ever worked with.
OK, that resolved it. The cron job now runs. Many thanks to all for your help. Cheers, Eric Frank Bax wrote:
At 01:22 PM 12/2/05, Eric E wrote:
Hi all, I'm running Suse Linux 9.3, and I'm having problems with cron not actually running cron jobs. I suspect this is the kind of profile issue that commonly happens with cron jobs, but I don't have any idea how to debug it.
For example, if as root, I run crontab -e and enter the following very simple cron job:
22 12 * * * /usr/bin/touch /root/hello.root
In /var/log/messages, I have the following output:
Dec 2 12:21:23 hypervisor1 crontab[7015]: (root) BEGIN EDIT (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) REPLACE (root) Dec 2 12:21:25 hypervisor1 crontab[7015]: (root) END EDIT (root) Dec 2 12:22:01 hypervisor1 /usr/sbin/cron[6536]: (root) RELOAD (tabs/root)
Nothing mysterious about it. It alsways works that way. The time is too close to current time. If you want something to run at 12:22, then you must make the change to crontab before 12:21. cron cannot RELOAD at 12:22 *and* execute a task at 12:22 that wasn't there at 12:21.
That's the way it works on every Linux and *bsd system I've ever worked with.
participants (6)
-
Bruce Marshall -
Eric E -
Frank Bax -
John Summerfield -
Ken Schneider -
Randall R Schulz