cron not running crontabs?
Hi, Susers! Suse 10.1, our cron is not running the crontab files nor the /etc/cron.daily/* files: GENERAL:/space/backups # date Sun Sep 10 14:04:49 CEST 2006 GENERAL:/space/backups # crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.XXXXHkpDsg installed on Fri Sep 8 10:34:28 2006) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) SHELL=/bin/bash # Run backups: 55 23 * * * cd /space/backups && ./navigating-backups >/dev/null This job is never running, despite having been installed a couple days ago. GENERAL:/space/backups # ps -ef | grep cron root 2945 1 0 Sep05 ? 00:00:00 /usr/sbin/cron What's the workaround for getting cron to "just work" as it should? i've never had (never noticed) this problem on previous Suse releases. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
* stephan beal <stephan@s11n.net> [09-10-06 08:22]:
Suse 10.1, our cron is not running the crontab files nor the /etc/cron.daily/* files:
is cron running?? ps ux|grep cron if not, yast2 -> system -> runlevels and set cron to run -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Sunday 10 September 2006 14:46, Patrick Shanahan wrote:
* stephan beal <stephan@s11n.net> [09-10-06 08:22]:
Suse 10.1, our cron is not running the crontab files nor the /etc/cron.daily/* files:
is cron running??
ps ux|grep cron
From the original post:
GENERAL:/space/backups # ps -ef | grep cron root 2945 1 0 Sep05 ? 00:00:00 /usr/sbin/cron
-- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-09-10 at 14:18 +0200, stephan beal wrote:
This job is never running, despite having been installed a couple days ago.
Then check with another job, a single command, running every two minutes till you get it running. My guess is that it doesn't like the syntax. Set the mailto variable to see the error. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBBqVtTMYHG2NR9URAnPuAKCJuFmmfTbOdAKHXgBt2xvBGj1XowCfRiYx Q22rmPAQpS5qKhstZefk4uY= =USZ/ -----END PGP SIGNATURE-----
On Sunday 10 September 2006 16:00, Carlos E. R. wrote:
The Sunday 2006-09-10 at 14:18 +0200, stephan beal wrote:
This job is never running, despite having been installed a couple days ago.
Then check with another job, a single command, running every two minutes till you get it running. My guess is that it doesn't like the syntax.
crontab: * * * * * touch /tmp/crontest Now: GENERAL:/tmp # for i in a a a a; do ls -la crontest; sleep 60; done Curiously, the job does indeed run. That said, there is absolutely nothing wrong with this: GENERAL:/space/backups # crontab -l ... SHELL=/bin/bash 55 23 * * * cd /space/backups && ./navigating-backups >/dev/null Except that cron refuses to run it. i've used this type of syntax for years in crontabs without any problems. The mentioned dirs and script file exit, and i can copy/paste that command to the console and it will run. i'm also unclear why cron scripts under the /etc/cron.* directories are not run. i first had my backup installed under /etc/cron.daily. /etc/crontab runs /usr/lib/crons/run-crons every 15 minutes (or is supposed to, anyway). In fact, /etc/crontab has the exact same syntax as my cron job: -*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 (wordwrapped) except for the curious leading '-', which i've never seen in crontabs before but is explained in 'man 5 crontab' (it prevents a syslog entry from being written when the job is run). i've also tried simplifying my cronjob to: 14 17 * * * /space/backups/navigating-backups >/dev/null and doing my 'cd /space/backups' in the script. No change. ??? i'm extremely confused -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
stephan beal wrote:
On Sunday 10 September 2006 16:00, Carlos E. R. wrote:
The Sunday 2006-09-10 at 14:18 +0200, stephan beal wrote:
This job is never running, despite having been installed a couple days ago. Then check with another job, a single command, running every two minutes till you get it running. My guess is that it doesn't like the syntax.
crontab:
* * * * * touch /tmp/crontest
Now:
GENERAL:/tmp # for i in a a a a; do ls -la crontest; sleep 60; done
Curiously, the job does indeed run. That said, there is absolutely nothing wrong with this:
GENERAL:/space/backups # crontab -l ... SHELL=/bin/bash 55 23 * * * cd /space/backups && ./navigating-backups >/dev/null
Could you try it with absolute path instead of ./navigating-backups? Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
On Sunday 10 September 2006 18:27, Sandy Drobic wrote:
SHELL=/bin/bash 55 23 * * * cd /space/backups && ./navigating-backups >/dev/null
Could you try it with absolute path instead of ./navigating-backups?
i tried that, but it didn't make any difference (as well it shouldn't). -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-09-10 at 17:18 +0200, stephan beal wrote:
14 17 * * * /space/backups/navigating-backups >/dev/null
and doing my 'cd /space/backups' in the script. No change.
??? i'm extremely confused
Well, I insist that you define the "mailto" variable. You will get the error report. And remove the dev/null thing and put a real file (or nothing, for the email). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBEh+tTMYHG2NR9URAv/rAJ9vc1ExpzF7PFpuwIURjPIG0XbdoQCfUHYS 1FHenI3ARZ17TB+BsFYkulg= =+XcR -----END PGP SIGNATURE-----
On Sunday 10 September 2006 19:16, Carlos E. R. wrote:
Well, I insist that you define the "mailto" variable. You will get the error report. And remove the dev/null thing and put a real file (or nothing, for the email).
i have set the mailto, and no mail is set. It's simply as if the job is ignored by cron. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
On Sunday 10 September 2006 21:08, stephan beal wrote:
On Sunday 10 September 2006 19:16, Carlos E. R. wrote:
Well, I insist that you define the "mailto" variable. You will get the error report. And remove the dev/null thing and put a real file (or nothing, for the email).
i have set the mailto, and no mail is set. It's simply as if the job is ignored by cron.
Have you tried rewriting the line? What is the character immediately following the 5th asterisk? Make sure it is a tab character
On Sunday 10 September 2006 21:22, Anders Johansson wrote:
On Sunday 10 September 2006 21:08, stephan beal wrote:
i have set the mailto, and no mail is set. It's simply as if the job is ignored by cron.
Have you tried rewriting the line?
Several times :(
What is the character immediately following the 5th asterisk? Make sure it is a tab character
It was a space, i've replaced it with a tab, but that doesn't make a difference (as it shouldn't). Vixie cron isn't as picky as Solaris cron. My crontab low looks like: SHELL=/bin/bash MAILTO=stephan 32 9 * * * /space/backups/navigating-backups (That's a tab between fields 5 and 6) And i get no mail, no output, no nothing. It's simply ignoring the cron job. The very minimal output should be something like "nothing to do", because the script is just running a makefile which might determine that all targets are up to date. Looking through last month's archives on this list, someone else had a similar problem and no solution was every proposed. It looks like i'm going to have to start, as a workaround, using 'at' jobs which automatically reschedule themselves after running. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-09-11 at 09:35 +0200, stephan beal wrote:
My crontab low looks like:
SHELL=/bin/bash MAILTO=stephan 32 9 * * * /space/backups/navigating-backups
Try with a new line afresh, something like 32 9 * * * /usr/local/bin/mybackup > /root/mybackup.log And ensure the script is executable. Make the first line in the script an echo thing. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBRzDtTMYHG2NR9URAiWeAJ9emtTaRype1NCZH/UQdbOliXyOwACglmdP YJTlIhGN7A12fWuC01qM9A4= =4CxJ -----END PGP SIGNATURE-----
On Mon, 2006-09-11 at 09:35 +0200, stephan beal wrote:
It was a space, i've replaced it with a tab, but that doesn't make a difference (as it shouldn't). Vixie cron isn't as picky as Solaris cron.
My crontab low looks like:
SHELL=/bin/bash MAILTO=stephan 32 9 * * * /space/backups/navigating-backups
(That's a tab between fields 5 and 6)
And i get no mail, no output, no nothing. It's simply ignoring the cron job. The very minimal output should be something like "nothing to do", because the script is just running a makefile which might determine that all targets are up to date.
Looking through last month's archives on this list, someone else had a similar problem and no solution was every proposed. It looks like i'm going to have to start, as a workaround, using 'at' jobs which automatically reschedule themselves after running.
I had a similar problem. On Sept. 3, I started a thread titled: "Cron Not Running Tasks". Someone sent me something to check (although I don't see it within the thread itself). They stated that if you change a crontab, cron needs several minutes before recognizing the change. As it turned out, that was my problem. I recently came over from Debian Linux. I was used to being able to change a time in a crontab to within a minute of the current time. It would run with no problem. With SuSE, changing the run time of a task to a time so close in the future would cause cron to not run the job at all. Perhaps you are doing this as well? Try changing the time for a task to something 10 or 15 minutes in the future and see if the cron daemon runs it then. It solved my problem. Cron is happily running my crontab tasks. Rick -- Rick's Law: What cannot be imagined will be accomplished by a fool. PGP Key Id: 9E1125E0
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-09-11 at 08:39 -0400, Rick Friedman wrote:
I had a similar problem. On Sept. 3, I started a thread titled: "Cron Not Running Tasks". Someone sent me something to check (although I don't see it within the thread itself). They stated that if you change a crontab, cron needs several minutes before recognizing the change. As it turned out, that was my problem.
Now that you mention that... Another problem happens depending on the editor used for cron files: if the timestamp of the dir holding the modified file doesn't change (act. the modtime), cron does not notice. This is documented, in fact. I remember that joe or mcedit had that problem, but I don't remember which one. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBWyitTMYHG2NR9URAqzSAKCDVPltmRz3LW32Mvw4SIK9OMv6xwCcCF0E cDph3zhpId5N6pqnt1d68Tw= =jx78 -----END PGP SIGNATURE-----
* Carlos E. R. <robin.listas@telefonica.net> [09-11-06 10:04]:
Another problem happens depending on the editor used for cron files: if the timestamp of the dir holding the modified file doesn't change (act. the modtime), cron does not notice. This is documented, in fact. I remember that joe or mcedit had that problem, but I don't remember which one.
probably mcedit, which I do not use. I do use joe and have no problems with cron :^). -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-09-11 at 10:18 -0400, Patrick Shanahan wrote:
Another problem happens depending on the editor used for cron files: if the timestamp of the dir holding the modified file doesn't change (act. the modtime), cron does not notice. This is documented, in fact. I remember that joe or mcedit had that problem, but I don't remember which one.
probably mcedit, which I do not use. I do use joe and have no problems with cron :^).
I remember I tested the issue, but not where I wrote it, except in the list O:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBZ7QtTMYHG2NR9URAtAVAJ4liO7bmRiFDBtCIny0CjZEwVNHiACfdOru vdA+YLLdTXkHsCKdwPJYjyY= =fEex -----END PGP SIGNATURE-----
On Monday 11 September 2006 16:03, Carlos E. R. wrote:
The Monday 2006-09-11 at 08:39 -0400, Rick Friedman wrote:
I had a similar problem. On Sept. 3, I started a thread titled: "Cron Not Running Tasks". Someone sent me something to check (although I don't see it within the thread itself). They stated that if you change a crontab, cron needs several minutes before recognizing the change. As it turned out, that was my problem.
Now that you mention that...
Another problem happens depending on the editor used for cron files: if the timestamp of the dir holding the modified file doesn't change (act. the modtime), cron does not notice. This is documented, in fact. I remember that joe or mcedit had that problem, but I don't remember which one.
i was using 'pico' - don't know if that's affected. The jobs are indeed now running. i can't explain why they didn't initially run. After creating a couple "bogus" jobs which only echo and such, and setting the cron time to "far" in the future (15 minutes), it appears to work. Stupid, but true. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
At 11:03 AM 9/11/06, stephan beal wrote:
On Monday 11 September 2006 16:03, Carlos E. R. wrote:
The Monday 2006-09-11 at 08:39 -0400, Rick Friedman wrote:
I had a similar problem. On Sept. 3, I started a thread titled: "Cron Not Running Tasks". Someone sent me something to check (although I don't see it within the thread itself). They stated that if you change a crontab, cron needs several minutes before recognizing the change. As it turned out, that was my problem.
Now that you mention that...
Another problem happens depending on the editor used for cron files: if the timestamp of the dir holding the modified file doesn't change (act. the modtime), cron does not notice. This is documented, in fact. I remember that joe or mcedit had that problem, but I don't remember which one.
i was using 'pico' - don't know if that's affected.
The jobs are indeed now running. i can't explain why they didn't initially run. After creating a couple "bogus" jobs which only echo and such, and setting the cron time to "far" in the future (15 minutes), it appears to work. Stupid, but true.
Two minutes is long enough. Cron checks the contab files on the "top" (zero seconds) of each minute. It needs to detect a change in the file at the top of a minute, before it can execute the command at the top of next minute. If you make a change to crontab file at 10:56:55, then time should be 10:58 or later for it to execute the same day, because change to file is detected at 10:57 and cannot execute at that time.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-09-11 at 17:03 +0200, stephan beal wrote:
Now that you mention that...
Another problem happens depending on the editor used for cron files: if the timestamp of the dir holding the modified file doesn't change (act. the modtime), cron does not notice. This is documented, in fact. I remember that joe or mcedit had that problem, but I don't remember which one.
i was using 'pico' - don't know if that's affected.
No, I just tested it. cer@nimrodel:~/tmp/p> l total 12 drwxr-xr-x 2 cer users 6 2006-08-29 20:06 ./ drwxr-xr-x 14 cer users 4096 2006-07-02 00:13 ../ cer@nimrodel:~/tmp/p> pico file cer@nimrodel:~/tmp/p> l total 16 drwxr-xr-x 2 cer users 17 2006-09-11 19:38 ./ drwxr-xr-x 14 cer users 4096 2006-07-02 00:13 ../ -rw-r--r-- 1 cer users 4 2006-09-11 19:38 file You see that the date of the directory changed. I tried again with mcedit and joe: both are ok in 10.1. Last time I tried this was in 9.3 and one failed, probably mcedit. Interesting... maybe someone read us when we where talking about it here las time :-)
The jobs are indeed now running. i can't explain why they didn't initially run. After creating a couple "bogus" jobs which only echo and such, and setting the cron time to "far" in the future (15 minutes), it appears to work. Stupid, but true.
Well... good that they work, even if we are not sure why... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBaA1tTMYHG2NR9URAgkIAJ4xe1YrnfVrGcVat7rNgxPPvcaR4gCfSmwI rjlJsZKzQDBv4IwCREkQoNM= =IhdK -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-09-10 at 21:08 +0200, stephan beal wrote:
Well, I insist that you define the "mailto" variable. You will get the error report. And remove the dev/null thing and put a real file (or nothing, for the email).
i have set the mailto, and no mail is set.
I don't understand that sentence. I mean you inlcude this in you crontab: SHELL=/bin/bash MAILTO="localuser" And remove that " > /dev/null" part of your line, you haven't commented on that. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBIGVtTMYHG2NR9URAvhhAJ0SGHxLXOsWDRm6SkDOEDzRaXyqHwCghmxl ZSZ7PRvVp2PtFFy6ljzHbxs= =dMiZ -----END PGP SIGNATURE-----
participants (7)
-
Anders Johansson -
Carlos E. R. -
Frank Bax -
Patrick Shanahan -
Rick Friedman -
Sandy Drobic -
stephan beal