Hi all,
are there any changes in cron behaviour on SUSE 11.0?
I’ve created a cronjob-file for a daily update process under /etc/cron.d
30 20 * * * root zypper up -y -t patch --skip-interactive
Well, the cronjob doesn’t run on SUSE 11.0 (worked fine since SUSE 9). Are there any changes?
Thanks in advance,
Andreas
Check cron is really running - just in case.
I had a similar problem a few months ago. I did a Web search and recall seeing some posts complaining that /etc/cron.d didn’t work like it used to.
I solved my problem by moving my cron job into a crontab in /var/spool/cron/tabs. Simply create a file with the appropriate username (in your case, root) and put the job in there. Remove the “root” username spec from the job (it’s implied by the name of the file when you run from a spool/tab).
Swerdna has an excellent how-to on using the crontabs. You can see the minor differences by following his advice.
HowTo: Cron Tables (Crontab) to Schedule Events in Suse Linux (openSUSE) 10.x, 11.x
If that doesn’t work, then as the previous poster suggested, ensure the cron itself is running: execute “server cron status” as root in a terminal, or use Yast -> System -> Services (Runlevels).
Hmm, /etc/cron.d has worked fine for me under 11.0 and now 11.1.
If you look in /var/log/messages, there should be a line at the time it tries to execute the job.
Thanks for all your answers!
Well, the cron deamon is running fine, but /var/log/message/doesn’t list the update job.
I’m using the /etc/crontab file for custom time/user configurations for some of the jobs. All these entries are executed normally. I’ve included the update command in this file, we’ll see the results tomorrow…
I wonder why are there so many possibilities to run cronjobs:
The only interesting difference is the one-file-per-user scenario with crontab -e
Seems to me a bit confusing…
In the beginning there were two locations, per user using crontab -e and the system crontab /etc/crontab.
/etc/cron.d is a logical extension of /etc/crontab. It allows packages to easily put and remove custom crontabs there without having to disturb the master crontab. It’s also a good place to put app specific crontabs, you can group a bunch of actions which might be run by different accounts, for say moodle.
/etc/cron.{hourly,daily,weekly,monthly} are actually caused from that initial entry in /etc/crontab which says /usr/lib/cron/run-crons
I know. It SHOULD work. But like andi303, it wouldn’t work in my case. Don’t know why and I can’t explain it.
But the fix is simple: just move it to a per-user crontab file in /var/spool, and it seems to work. Go figure.
Did you remember that crontabs in /etc/cron.d require the account name in the 6th field?
Yep, and if you look at andi303’s post, it’s done that way. I tried it that way, too.
Maybe it just hated me.
Well, after a long time, i’ve found the solution. Maybe someone can use this information:
I’ve copied the cron files from a NAS back to the server, and i think it was just an encoding problem.
Using
cat /var/log/messages | grep cron
, i’ve found these lines:
Mar 3 00:55:01 bscw /usr/sbin/cron[21357]: (root) CMD ( ^I/usr/bin/freshclam --quiet)
Mar 3 01:00:01 bscw /usr/sbin/cron[21540]: (root) CMD ( ^I/usr/bin/clamscan -r --quiet --exclude-dir=/srv/nas /tmp /srv )
As you can see, there are two additional characters in front of the command (^I). I’ve no idea what this is, but i think it’s a problem from different tabulator encoding. (Hope i described this correctly)
I’ve just used vi for editing the crontab and replaced the tabulator spacing. Since then, everything works fine.
Stupid…