Bug 1016551

Summary: kernel: time.c: can't update CMOS clock from 59 to 0
Product: Red Hat Enterprise Linux 5 Reporter: Julio Entrena Perez <jentrena>
Component: kernelAssignee: Prarit Bhargava <prarit>
Status: CLOSED WONTFIX QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.10CC: btotty
Target Milestone: rcKeywords: EasyFix
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-04 16:51:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Julio Entrena Perez 2013-10-08 10:41:18 UTC
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."

Comment 2 Prarit Bhargava 2013-11-04 16:51:24 UTC
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.