This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 152396 - automatic cron reload delays new jobs
automatic cron reload delays new jobs
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
: 159441 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-29 03:02 EST by Need Real Name
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: vixie-cron-4.1-82.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-05 12:05:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2005-03-29 03:02:33 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):


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:
Comment 1 Need Real Name 2005-03-29 03:03:47 EST
(The second cat /tmp/date - the one that works - should have a time of 09:57:02)
Comment 2 Jason Vas Dias 2005-04-05 12:05:35 EDT
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".
Comment 3 Need Real Name 2005-04-05 13:49:16 EDT
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?
Comment 4 Jason Vas Dias 2005-04-05 14:01:38 EDT
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 .


Comment 5 Need Real Name 2005-04-05 14:07:28 EDT
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?
Comment 6 Need Real Name 2005-05-12 13:12:43 EDT
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!
Comment 7 Jason Vas Dias 2005-05-12 13:32:17 EDT
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 .
Comment 8 Need Real Name 2005-05-12 14:53:30 EDT
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.
Comment 9 Jason Vas Dias 2005-06-02 14:22:11 EDT
*** Bug 159441 has been marked as a duplicate of this bug. ***
Comment 10 Need Real Name 2007-08-20 08:20:53 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.