Bug 192783 - Job delayed after using crontab -e
Job delayed after using crontab -e
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vixie-cron (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Marcela Mašláňová
Ben Levenson
: Reopened
Depends On:
Blocks: 176344
  Show dependency treegraph
Reported: 2006-05-22 18:17 EDT by Jose Plans
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2007-0685
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-02 04:05:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch fixing the database delay bug. (763 bytes, patch)
2006-05-22 18:17 EDT, Jose Plans
no flags Details | Diff

  None (edit)
Description Jose Plans 2006-05-22 18:17:01 EDT
Description of problem:
Vixie-cron versions 4.x delay the execution of new updated jobs.
If one user edits its cron table at time 0:00, cron wont update its informations
on the first loop but after it, delaying the execution of the task by 1 loop.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use an account.
2. Edit its crontab. crontab -e, adding a job (for example * * * * * user
/bin/ls /tmp)
3. Wait for the job to be executed.
Actual results:
The job is executed later than expected :

Apr 13 10:00:10 chancroid crontab[3929]: (ctatman) END EDIT (ctatman)
Apr 13 10:00:10 chancroid crontab[3941]: (ctatman) LIST (ctatman)
Apr 13 10:01:01 chancroid crond[3944]: (root) CMD (run-parts /etc/cron.hourly)
Apr 13 10:01:01 chancroid crond[1537]: (ctatman) RELOAD (cron/ctatman)
Apr 13 10:02:01 chancroid crond[3954]: (ctatman) CMD (user  /bin/ls /tmp/)

The job is delayed by 1 minute.

Expected results:

/var/log/cron with vixie-cron-4.1-11test.EL3 installed:
Apr 26 16:11:11 chancroid crontab[10985]: (ctatman) BEGIN EDIT (ctatman)
Apr 26 16:11:33 chancroid crontab[10985]: (ctatman) REPLACE (ctatman)
Apr 26 16:11:33 chancroid crontab[10985]: (ctatman) END EDIT (ctatman)
Apr 26 16:11:33 chancroid crontab[10989]: (ctatman) LIST (ctatman)
Apr 26 16:12:01 chancroid crond[1486]: (ctatman) RELOAD (cron/ctatman)
Apr 26 16:12:01 chancroid crond[10992]: (ctatman) CMD (ctatman  /bin/ls /tmp/) 

The job is executed in time.

Additional info:

Attached you will find a patch that solves the issue. The main loop has
load_database called too late, and after the job execution tasks; setting it up
after cron_sleep and before find_jobs, I believe, is the right place to populate
the infos to the job descriptions.

It is also true for FC5.

Comment 1 Jose Plans 2006-05-22 18:17:02 EDT
Created attachment 129833 [details]
Patch fixing the database delay bug.
Comment 2 Jason Vas Dias 2006-05-26 18:14:57 EDT
There are several reasons why jobs should be loaded AFTER find_jobs; 
o jobs could be removed, so we could end up with a child returning for
  a job that has been removed.
o we don't want any processing that may need to be done to affect the
  runs of the current jobs; eg. a user could create a massive job
  the loading of which could delay the runs of the current job list.

With the current implementation, it is better that the current job list 
should be run first, and then load database can modify the job list after
it has been run.

I am working on a cron enhancement that will remove this limitation of the

This is not actually a bug, as cron makes no guarantees about when jobs will
be loaded, only about when they are run after loading.

I will consider it as an enhancement and will try out the fix in fedora releases
before submitting it to a RHEL release.
Comment 5 RHEL Product and Program Management 2006-09-05 15:38:47 EDT
The component this request has been filed against is not planned for inclusion
in the next update. The decision is based on weighting the priority and number
of requests for a component as well as the impact on the Red Hat Enterprise
Linux user-base: other components are considered having higher priority and the
number of changes we intend to include in update cycles is limited.
Comment 6 RHEL Product and Program Management 2006-09-05 15:49:07 EDT
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 
Comment 8 Marcela Mašláňová 2006-09-20 08:09:52 EDT
vixie-cron-4.1-_44-delayed_database.patch solves this problem, should be 
included in RHEL.
Comment 14 Marcela Mašláňová 2007-05-11 07:43:47 EDT
Frozen in errata, could we propose it for 4.6?
Comment 19 Red Hat Bugzilla 2007-08-02 04:05:55 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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