Created attachment 116593 [details] vixie-cron-fix-list-trashing.patch
Description of problem: List corruption when items are removed from /etc/cron.d Version-Release number of selected component (if applicable): vixie-cron-4.1-3_EL3 How reproducible: Every time Steps to Reproduce: # cd /etc/cron.d # service crond stop # for i in a1 a2 a3 a4; do echo "* * * * * root /bin/echo $i >> /tmp/file" > $i ; done # for i in a2 a3 a4; do touch -r a1 $i; done # service crond start # touch /tmp/file # tail -f /tmp/file (Wait until the next minute comes) # rm a1 (Wait until the next minute comes) Actual results: a1 a2 a3 a4 <rm file> a1 a3 a3 Expected results: a1 a2 a3 a4 <rm file> a2 a3 a4 Additional info: Tested with current RHEL3 U5 vixie-cron and RHEL3 U6 candidate, probably also affects RHEL4.
This issue seems to be to do with the "2 minute lag" issue (bug 159441, bug 152396), and is NOT a bug. I cannot reproduce the problem - if you wait at least two minutes, crontab edits / creates / removes ALWAYS take effect - so your line above "(Wait until the next minute comes)" should be "(Wait until at least two minutes elapse)" and the problem would not occur. In order to guarantee that at least 60 seconds must elapse between job executions, vixie-cron performs the execution of the current job list before modifying it with any modified crontab files; so if a change is made at 00:00:30, the list as at 00:00:00 is executed at 00:01:00, and the new list is not executed until 00:02:00 . So changes can take up to 2 minutes before taking effect . The patch you suggest is wrong: it changes processing of system crontabs in /etc/cron.d, which have a sixth "username" field in cronjob lines, to be as for user crontabs - the sixth field would then cause problems ( system crontabs are processed by calling "process_crontab" with a second "fname" argument of NULL ), which causes the code to expect a sixth username field in crontabs.
Fair enough about the 2-minute lag (and the broken patch for the matter), but if you try out the test case above you will see that the list is indeed trashed, as the wrong entry will be removed from the "db" linked list. It will remove the first entry in the old_db that matches the "*system*" user, whatever that happens to be. crond does *not* recover, and the list is still broken after 2 (or more) minutes.
Yes, I've just now seen this. It appears to be a latent bug with vixie-cron-3.0.1-* as well : # rpm -q vixie-cron vixie-cron-3.0.1-76_EL3 # service crond stop # cd /etc/cron.d # for i in 1 2 3 4; do echo '* * * * * root echo `date` job '$i'>>/tmp/cron.log' > c$i; done # cat c* * * * * * root echo `date` job 1>>/tmp/cron.log * * * * * root echo `date` job 2>>/tmp/cron.log * * * * * root echo `date` job 3>>/tmp/cron.log * * * * * root echo `date` job 4>>/tmp/cron.log # service crond start ( wait 1min ) # cat /tmp/cron.log Mon Jul 11 12:10:00 EDT 2005 job 2 Mon Jul 11 12:10:00 EDT 2005 job 4 Mon Jul 11 12:10:01 EDT 2005 job 1 Mon Jul 11 12:10:01 EDT 2005 job 3 # echo '-- rm 1' >> /tmp/cron.log; rm -f c1 ( wait 1min ) # cat /tmp/cron.log Mon Jul 11 12:10:00 EDT 2005 job 2 Mon Jul 11 12:10:00 EDT 2005 job 4 Mon Jul 11 12:10:01 EDT 2005 job 1 Mon Jul 11 12:10:01 EDT 2005 job 3 -- rm 1 Mon Jul 11 12:11:01 EDT 2005 job 1 Mon Jul 11 12:11:01 EDT 2005 job 3 Mon Jul 11 12:11:01 EDT 2005 job 3 I can't believe this never surfaced before - well spotted! I'm now working on a fix for this issue, as well as for 154920 / 162022, as top priority.
Created attachment 116613 [details] patch to handle multiple crontab files in /etc/cron.d for *system* user This has been a bug ever since Red Hat introduced a crond with support for multiple system crontabs in /etc/cron.d/ . The algorithm for reloading crontabs assumed ONE CRONTAB FILE PER USER, as is the case for /etc/crontab and /var/spool/cron/* . The fix is to store the crontab name in the user struct and search for both user name and crontab name in find_user when the crontab is an /etc/cron.d crontab . I'll submit this patch to Rawhide & FC-4 and then wait a couple of weeks before submitting to RHEL-3 / RHEL-4 to let any issues with it come to light - I can't find any so far during testing.
This is now fixed with vixie-cron-4.1-8.EL3, available from: http://people.redhat.com/~jvdias/cron/RHEL-3/4.1-8.EL3 Please try out the new version and let me know of any issues - thanks.
This bug is fixed with vixie-cron-4.1-8_EL3, available from: http://people.redhat.com/~jvdias/cron/RHEL-3 and should be considered for inclusion in RHEL-3-U7 .
Fixed with vixie-cron-4.1-10.EL3, currently in RHEL-3-U7 with errata RHSA-2005:0117.