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.
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)
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) Thanks, Yves.
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. 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.
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: * http://people.redhat.com/jplans/.222464/ Jose Internal Status set to 'Waiting on Support' This event sent from IssueTracker by jplans issue 112011
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