Hide Forgot
Description of problem: "kernel: time.c: can't update CMOS clock from 59 to 0" logged every now and then to /var/log/message with WARNING log level. Version-Release number of selected component (if applicable): kernel 2.6.18-348.6.1.el5. How reproducible: Randomly, always at o'clock times: $ grep "can't" var/log/messages* var/log/messages:Oct 3 08:00:00 hostname kernel: time.c: can't update CMOS clock from 59 to 0 var/log/messages.1:Sep 28 07:00:01 hostname kernel: time.c: can't update CMOS clock from 59 to 0 var/log/messages.4:Sep 5 19:00:00 hostname kernel: time.c: can't update CMOS clock from 59 to 0 var/log/messages.5:Aug 31 18:00:01 hostname kernel: time.c: can't update CMOS clock from 59 to 0 Steps to Reproduce: 1. Unknown, wait for it to happen. 2. 3. Actual results: "kernel: time.c: can't update CMOS clock from 59 to 0" messages are logged with WARNING log level. WARNING log level entries trigger alerts on customer's monitoring system. Expected results: "kernel: time.c: can't update CMOS clock from 59 to 0" messages are logged with DEBUG log level so they don't end up in /var/log/messages . Additional info: - Got the following feedback from Jeremy Harris: "It's not a problem and the messages can be ignored; they're merely informational. To avoid timezone-related issues the code avoids updating the CMOS clock to match "reality" when such a change would involve modifying the hour. The one-minute-to-the hour (minute 59) to on-the hour (minute 0) would require doing just that. The code should get around to applying the update some time later; the only impact would be if the system crashed in the interim and, on next reboot, really cared about precise time before NTP became synced. However, with the usual accurace of system CMOS clocks, anyone who relies on the latter (time precision without NTP) is probably hosed anyway." - According to http://www.ntp.org/ntpfaq/NTP-s-trbl-spec.htm#Q-LINUX-SET-RTC-MMSS : "The solution for this problem is either to wait a few minutes, or to install a kernel patch that fixes the problem."
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 5, and therefore is being closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide a sufficient business justification in order to re-open it.