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): vixie-cron-4.1-36 How reproducible: Always. 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. jose
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 implementation. 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. http://rhn.redhat.com/errata/RHBA-2007-0685.html