Fedora Account System
Red Hat Associate
Red Hat Customer
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Epiphany/1.4.4 Description of problem: If I add a new entry to /etc/crontab, the change is noted within a minute, and a RELOAD message is printed to /var/log/cron Confusingly, the reload doesn't seem to take effect until a minute later. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Run tail -f /var/log/cron 09:55:30: Add new entry to /etc/crontab: * * * * * root echo $(date) > /tmp/date 09:56:01: Notice reload of crontab in /var/log/cron 09:56:02: cat /tmp/date cat: /tmp/date: No such file or directory 09:57:01: Notice cron has run the new command 09:56:02: cat /tmp/date Tue Mar 29 09:57:01 CEST 2005 Actual Results: A new command added to crontab takes up to two minutes to be run. Crontab does not notice new commands added to crontab despite the update being noticed. Expected Results: A crontab reload should run new commands. Additional info:
(The second cat /tmp/date - the one that works - should have a time of 09:57:02)
This is not a bug, but is the way cron works. CRON is not a tool for running programs at specific times - for that purpose, use at(1) . CRON is a tool for running programs at periodic intervals which must not be less than one minute (60 seconds). Every minute, cron runs jobs scheduled for that minute, and then examines its crontab locations for new, deleted or changed crontab files, and loads changed crontab files to contruct its schedule for successive minutes; so the time from making a change to the time the change takes effect will always be at least two minutes. If cron immediately executed newly created schedules every minute, it could not guarantee that at least 60 seconds elapse between job executions, a bug with previous cron versions. Hence, this bug is being closed as "not a bug".
I'm not sure I understand. From the man page: "Cron then wakes up every minute, examining all stored crontabs, checking each command to see if it should be run in the current minute." So according to the man page, cron wakes up, looks a the crontab, and runs the jobs. Not doing this is a bug surely?
By "stored crontabs" the man-page means "crontabs stored in memory". The way cron loads jobs at least one minute before running them means that it can guarantee that no job will run twice within 60 seconds. This was a serious bug with cron-3.0.x : bug 106578 .
Ah. Well I suppose that makes more sense then. You don't want to delay all the other jobs just because cron has changed, but I still think that the behaviour doesn't match the man page. Can we reopen this bug as a bug in the man page, for not making things clear?
Annoyingly, this bug also means that when you have a dieing machine with a rising load average, killing the runaway process, then disabling the cron job, doesn't disable the cron job until the next time round. Nice!
I will annotate the man-page accordingly in the next cron version. RE: Comment #6 : This is NOT a bug, as explained above. If you have a dieing machine, due to a runaway cron job process A) why not do 'service crond stop' or 'reboot' rather then edit a crontab ? B) the cron job should not have been added until the process was tested .
It depends how you look at it. From the programmer's point of view it isn't a bug. From the user's, it is. Anyway, please don't make assumptions. In reply: A) Why not stop the cron daemon? Why not reboot? Because the machine was still working, if slowly. There's no need to make things worse by killing other jobs just because one job goes wrong. B) logrotate is shipped by you, you test it.
*** Bug 159441 has been marked as a duplicate of this bug. ***
This bug, whereby cron would reload crontab AFTER running the cron jobs (and thereby ignoring any changes less than 2 minutes old) is fixed in the current version.