Bug 222464 - crond failed "Days of week" after a few hours on 1st/Jan
crond failed "Days of week" after a few hours on 1st/Jan
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vixie-cron (Show other bugs)
4.0
All Linux
high Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
:
Depends On:
Blocks: 223662 232439 236329
  Show dependency treegraph
 
Reported: 2007-01-12 12:36 EST by masanari iida
Modified: 2014-01-16 13:15 EST (History)
8 users (show)

See Also:
Fixed In Version: RHBA-2008-0115
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-05 07:36:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description masanari iida 2007-01-12 12:36:02 EST
Description of problem:
crond failed to decode "Days of week" entry within crontab 
after 1st system reboot of 1st/Jan. 2007. 
System started to run different "days of week" entry of the crontab.
(example: 2 days ago.)

Version-Release number of selected component (if applicable):
Affected: vixie-cron-4.1-10 and vixie-cron-4.1-11
NOT affected:  vixie-cron-3.


How reproducible:
Always reproducible the system clock is set after 1st of Jan. 2007.
AND crond is started after 2007.

If the system clock is set before 1st/Jan. 2007, it never happened.
If the crond never re-started after 2007, it never happened.

Steps to Reproduce:
1. Create crontab entries.

* * * * 0 date >> /tmp/sun.txt
* * * * 1 date >> /tmp/mon.txt
* * * * 2 date >> /tmp/tue.txt
* * * * 3 date >> /tmp/wed.txt
* * * * 4 date >> /tmp/thu.txt
* * * * 5 date >> /tmp/fri.txt
* * * * 6 date >> /tmp/sat.txt
* * * * 7 date >> /tmp/sun.txt

* * * * sat date >> /tmp/sat_sat.txt

2. Set the system time to  12/31  23:50, 2006.
# date 123123502006

3. Check /tmp. (It is now 23:51, 12/31, 2006.)
   /tmp/sun.txt is written. (This is expected.)

4.  Wait until  1/1 00:05,  2007.
   
5. Check /tmp (It is now 1/1 00:06, 2007)
   /tmp/mon.txt is written. (This is expected.)

6. Restart crond.
   # /etc/init.d/crond restart

7. Check /tmp  (It is now 1/1 00:08, 2007)
   
   Actual results:
   /tmp/sat.txt and /tmp/sat_sat.txt are written.

   Expected results:
   /tmp/mon.txt should be written.

I confirmed multiple system encountered same symptom 
with this steps.

Additional info:

System IA32(Intel)
kernel 2.4.21-32.0.1
tzdata-2006m-3.el3
vixie-cron-4.1-10.EL3

# rpm -qa |grep glibc
glibc-utils-2.3.2-95.27
glibc-headers-2.3.2-95.27
glibc-2.3.2-95.27
compat-glibc-7.x-2.2.4.32.6
glibc-common-2.3.2-95.27
glibc-devel-2.3.2-95.27
glibc-profile-2.3.2-95.27
glibc-kernheaders-2.4-8.34.1

FYI. 
I don't see this symptom on my private FC5.
Comment 1 masanari iida 2007-01-15 01:02:16 EST
Narrow Down the problem....

(1) The symptom occured a crond restarted between Jan 1st 0:00AM - 9:00AM, 
any year.

FYI,  the test environment has TZ=JST-9. 

(2) If you don't restart crond between the period, nothing may happen.

(3) Once you see the symptom, restart the crond AFTER Jan 1st 9:00AM may 
fix the problem.

[How to reproduce]

(0)  Confirm your local time zone.
# more /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=false
ARC=false

(1)  date 010108572003 
(2)  /etc/init.d/crond restart   
(3)  Confirm mon.txt is exist under /tmp. 
This is wrong file, because 1st/Jan, 2003 is Wednesday.

# ls -l
-rw-r--r--    1 root     root           29 Jan  1 08:58 mon.txt

# date
Wed Jan  1 08:59:17 JST 2003

(4) After 9:01(AM), you restart the crond.
# /etc/init.d/crond restart

(5) Confirm which file is used.
-rw-r--r--    1 root     root           29 Jan  1 09:03 wed.txt 
-rw-r--r--    1 root     root          145 Jan  1 09:02 mon.txt  

mon.txt is used _BEFORE_ the crond restarted.  (Wrong file)
_AFTER_ crond restart in step 4, wed.txt is used. (Correct file)




Comment 2 masanari iida 2007-01-16 05:35:27 EST
Test on RHEL4 + vixie-cron-4.1-20_EL, follow the comment #1 step-by-step.
I have confirmed the same problem exist on RHEL4.
Comment 3 Kevin Krafthefer 2007-01-18 11:00:45 EST
this came in late for 3.9; moving to 4.6
Comment 4 Yves Begrand 2007-01-19 13:30:53 EST
This would likely fix the problem:

--- vixie-cron-4.1/misc.c.new-year	2007-01-19 12:19:26.000000000 +0000
+++ vixie-cron-4.1/misc.c	2007-01-19 13:50:22.000000000 +0000
@@ -748,7 +748,7 @@
 	if (local->tm_year < gmt.tm_year)
 		offset -= 24 * 3600;
 	else if (local->tm_year > gmt.tm_year)
-		offset -= 24 * 3600;
+		offset += 24 * 3600;
 	else if (local->tm_yday < gmt.tm_yday)
 		offset -= 24 * 3600;
 	else if (local->tm_yday > gmt.tm_yday)

Thanks,

Yves.
Comment 5 Marcela Mašláňová 2007-01-22 05:43:28 EST
related to #223662
Patch available, fixed in devel.
Comment 9 RHEL Product and Program Management 2007-03-09 19:53:03 EST
This bugzilla had previously been approved for engineering
consideration but Red Hat Product Management is currently reevaluating
this issue for inclusion in RHEL4.6.
Comment 12 masanari iida 2007-11-15 19:44:24 EST
I just found RHEL4.6 has released.
vixie-cron package has been updated.
https://rhn.redhat.com/errata/RHBA-2007-0685.html
178836 - Editing crontab ("crontab -e") too quickly causes missed updates.
192783 - Job delayed after using crontab -e
221856 - Cron does not detect changed symlink

It seemed this bug has not been included on RHEL4.6.
I just curious why RH didn't fix it.
Comment 13 Marcela Mašláňová 2007-11-16 03:45:11 EST
I'm suggesting to ask support.
Comment 17 Curtis Taylor 2008-01-11 19:24:57 EST
Note: vixie-cron's get_gmtoff() is reported to have borrowed this algorithm from
sendmail.  Sendmail's arpadate() from apradate.c has the exact correction listed
in comment #4.
Comment 24 RHEL Product and Program Management 2008-02-01 14:10:27 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 28 RHEL Product and Program Management 2008-02-06 03:39:53 EST
This bugzilla was reviewed by QE as a non-FasTrack request.
It has since been proposed for FasTrack. The qa_ack has 
been reset. QE needs to re-review this bugzilla for FasTrack.
Comment 33 Issue Tracker 2008-02-26 06:51:26 EST
Please provide feedback on the below link if possible:
* http://people.redhat.com/jplans/.222464/
     Jose

Internal Status set to 'Waiting on Support'

This event sent from IssueTracker by jplans 
 issue 112011
Comment 39 errata-xmlrpc 2008-03-05 07:36:10 EST
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-2008-0115.html

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