Bug 162887

Summary: [PATCH] List corruption when items are removed from /etc/cron.d
Product: Red Hat Enterprise Linux 3 Reporter: Bastien Nocera <bnocera>
Component: vixie-cronAssignee: Jason Vas Dias <jvdias>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: benl, fenlason, nalin, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHSA-2005:0117 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-01 17:47:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 161600, 163889    
Attachments:
Description Flags
vixie-cron-fix-list-trashing.patch
none
patch to handle multiple crontab files in /etc/cron.d for *system* user none

Description Bastien Nocera 2005-07-11 10:03:43 UTC
Created attachment 116593 [details]
vixie-cron-fix-list-trashing.patch

Comment 1 Bastien Nocera 2005-07-11 10:03:43 UTC
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.

Comment 2 Jason Vas Dias 2005-07-11 15:00:00 UTC
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.




Comment 3 Bastien Nocera 2005-07-11 15:57:23 UTC
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 16:23:29 UTC
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.

Comment 5 Jason Vas Dias 2005-07-11 18:17:44 UTC
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 23:32:15 UTC
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.
 

Comment 12 Jason Vas Dias 2005-10-14 15:31:55 UTC
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 .

Comment 15 Jason Vas Dias 2006-05-01 17:47:14 UTC
Fixed with vixie-cron-4.1-10.EL3, currently in RHEL-3-U7 with errata
RHSA-2005:0117.