Red Hat Bugzilla – Bug 192783
Job delayed after using crontab -e
Last modified: 2007-11-30 17:07:25 EST
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):
Steps to Reproduce:
1. Use an account.
2. Edit its crontab. crontab -e, adding a job (for example * * * * * user
3. Wait for the job to be executed.
The job is executed later than expected :
Apr 13 10:00:10 chancroid crontab: (ctatman) END EDIT (ctatman)
Apr 13 10:00:10 chancroid crontab: (ctatman) LIST (ctatman)
Apr 13 10:01:01 chancroid crond: (root) CMD (run-parts /etc/cron.hourly)
Apr 13 10:01:01 chancroid crond: (ctatman) RELOAD (cron/ctatman)
Apr 13 10:02:01 chancroid crond: (ctatman) CMD (user /bin/ls /tmp/)
The job is delayed by 1 minute.
/var/log/cron with vixie-cron-4.1-11test.EL3 installed:
Apr 26 16:11:11 chancroid crontab: (ctatman) BEGIN EDIT (ctatman)
Apr 26 16:11:33 chancroid crontab: (ctatman) REPLACE (ctatman)
Apr 26 16:11:33 chancroid crontab: (ctatman) END EDIT (ctatman)
Apr 26 16:11:33 chancroid crontab: (ctatman) LIST (ctatman)
Apr 26 16:12:01 chancroid crond: (ctatman) RELOAD (cron/ctatman)
Apr 26 16:12:01 chancroid crond: (ctatman) CMD (ctatman /bin/ls /tmp/)
The job is executed in time.
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.
Created attachment 129833 [details]
Patch fixing the database delay bug.
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.
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.
Product Management has reviewed and declined this request. You may appeal this
decision by reopening this request.
vixie-cron-4.1-_44-delayed_database.patch solves this problem, should be
included in RHEL.
Frozen in errata, could we propose it for 4.6?
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.