Bug 159441 - One minute delay updating cron tables
One minute delay updating cron tables
Status: CLOSED DUPLICATE of bug 152396
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vixie-cron (Show other bugs)
4.0
All Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-02 13:57 EDT by Patrick Melo
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:08:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrick Melo 2005-06-02 13:57:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Description of problem:
Changes to crontab using crontab -e does not take effect the following minute, there is an extra minute delay.

If I run "crontab -e", add "* * * * * touch /tmp/1" and quit vi at 10:00:01, the job is first run at 10:02.  If I run "crontab -e", remove the entry and quit vi at 10:05:01, then the last time the job will be run will be 10:06.

Apparently the existing tables in memory are run and THEN they are updated from the crontab file.  I am running Red Hat Enterprise Linux ES release 4 (Nahant) which uses vixie-cron-4.1-20_EL.  I get the same behavior with Fedora Core release 3 (Heidelberg) with the latest updates which uses vixie-cron-4.1-33_FC3.  

On Red Hat Linux release 7.1 (Seawolf) which uses vixie-cron-3.0.1-62, the changes to the crontab files take effect the next minute, there is no one minute delay.


Version-Release number of selected component (if applicable):
vixie-cron-4.1-20_EL

How reproducible:
Always

Steps to Reproduce:
See description.

Additional info:
Comment 1 Jason Vas Dias 2005-06-02 14:22:04 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 ( bug #106578 ).

An enhanced version of cron is being developed with a more 
complex scheduling algorithm, which will look at other ways
of guaranteeing that at least one minute elapses between 
job executions while supporting instant job reloading; at
the moment, this entails a complete re-design of the way
cron works. This version should be ready for RHEL-5 .




*** This bug has been marked as a duplicate of 152396 ***
Comment 2 Red Hat Bugzilla 2006-02-21 14:08:20 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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