On Sunday 10 September 2006 14:46, Patrick Shanahan wrote:

* stephan beal [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

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

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

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: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

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

* Carlos E. R. [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

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

-----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-----