Red Hat Bugzilla – Bug 222464
crond failed "Days of week" after a few hours on 1st/Jan
Last modified: 2014-01-16 13:15:10 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.
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)
/tmp/sat.txt and /tmp/sat_sat.txt are written.
/tmp/mon.txt should be written.
I confirmed multiple system encountered same symptom
with this steps.
# rpm -qa |grep glibc
I don't see this symptom on my private FC5.
Narrow Down the problem....
(1) The symptom occured a crond restarted between Jan 1st 0:00AM - 9:00AM,
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
(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
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)
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.
this came in late for 3.9; moving to 4.6
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)
related to #223662
Patch available, fixed in devel.
This bugzilla had previously been approved for engineering
consideration but Red Hat Product Management is currently reevaluating
this issue for inclusion in RHEL4.6.
I just found RHEL4.6 has released.
vixie-cron package has been updated.
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.
I'm suggesting to ask support.
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.
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 "?".
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.
Please provide feedback on the below link if possible:
Internal Status set to 'Waiting on Support'
This event sent from IssueTracker by jplans
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.