Bug 162887 - [PATCH] List corruption when items are removed from /etc/cron.d
[PATCH] List corruption when items are removed from /etc/cron.d
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: vixie-cron (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brock Organ
Depends On:
Blocks: 161600 163889
  Show dependency treegraph
Reported: 2005-07-11 06:03 EDT by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHSA-2005:0117
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-01 13:47:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
vixie-cron-fix-list-trashing.patch (472 bytes, patch)
2005-07-11 06:03 EDT, Bastien Nocera
no flags Details | Diff
patch to handle multiple crontab files in /etc/cron.d for *system* user (2.72 KB, patch)
2005-07-11 14:17 EDT, Jason Vas Dias
no flags Details | Diff

  None (edit)
Description Bastien Nocera 2005-07-11 06:03:43 EDT
Created attachment 116593 [details]
Comment 1 Bastien Nocera 2005-07-11 06:03:43 EDT
Description of problem:
List corruption when items are removed from /etc/cron.d

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

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:
<rm file>

Expected results:
<rm file>

Additional info:
Tested with current RHEL3 U5 vixie-cron and RHEL3 U6 candidate, probably also
affects RHEL4.
Comment 2 Jason Vas Dias 2005-07-11 11:00:00 EDT
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

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.

Comment 3 Bastien Nocera 2005-07-11 11:57:23 EDT
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.
Comment 4 Jason Vas Dias 2005-07-11 12:23:29 EDT
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
# 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.
Comment 5 Jason Vas Dias 2005-07-11 14:17:44 EDT
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.
Comment 6 Jason Vas Dias 2005-07-11 19:32:15 EDT
This is now fixed with vixie-cron-4.1-8.EL3, available from:
Please try out the new version and let me know of any issues - thanks.
Comment 12 Jason Vas Dias 2005-10-14 11:31:55 EDT
This bug is fixed with vixie-cron-4.1-8_EL3, available from:
and should be considered for inclusion in RHEL-3-U7 .
Comment 15 Jason Vas Dias 2006-05-01 13:47:14 EDT
Fixed with vixie-cron-4.1-10.EL3, currently in RHEL-3-U7 with errata

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