Red Hat Bugzilla – Bug 152396
automatic cron reload delays new jobs
Last modified: 2007-11-30 17:11:02 EST
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):
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.
(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
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
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.
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.
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