Bug 2596

Summary: Cron is confused by Y2K tests
Product: [Retired] Red Hat Linux Reporter: innov8
Component: crontabsAssignee: Crutcher Dunnavant <crutcher>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 5.1CC: innov8
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-04-10 21:59:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description innov8 1999-05-06 13:03:39 UTC
Upon changing the date to dec 31 1999 using date --set, and
waiting for the rollover to jan 1 2000 the crond ran it's
jobs as normal.  Using date --set again and setting the
date back to normal the crond would not run any of it's
jobs.  The log file for the crond reported nothing.
Killing and restarting the daemon left and error in the
crond stating that the PID was already in use.  None of the
crontab files in either /etc/crontab or /var/spool/user
were modified when the date was jan 1.  The problem was
resolved by rebooting the machine.

Comment 1 Jeff Johnson 1999-05-06 16:24:59 UTC
*** Bug 2597 has been marked as a duplicate of this bug. ***

Upon changing the date to dec 31 1999 using date --set, and
waiting for the rollover to jan 1 2000 the crond ran it's
jobs as normal.  Using date --set again and setting the
date back to normal the crond would not run any of it's
jobs.  The log file for the crond reported nothing.
Killing and restarting the daemon left and error in the
crond stating that the PID was already in use.  None of the
crontab files in either /etc/crontab or /var/spool/user
were modified when the date was jan 1.  The problem was
resolved by rebooting the machine.Time -- unlike clocks and computers -- is a monotonically
increqasing function. Crond is patiently waiting for the
computer to catch up.