Bug 885770 - Chrony not always setting hw clock correctly
Chrony not always setting hw clock correctly
Status: CLOSED DUPLICATE of bug 816752
Product: Fedora
Classification: Fedora
Component: chrony (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-12-10 10:27 EST by Bob Rentschler
Modified: 2012-12-13 05:24 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-12-13 04:16:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bob Rentschler 2012-12-10 10:27:56 EST
Description of problem:
Chrony can fail to set the hardware clock leading to incorrect time on boot, in my case off by one hour after a DST change.

Version-Release number of selected component (if applicable): 

How reproducible: Always

Steps to Reproduce:
1. Set hardware clock to incorrect value.
2. reboot system

(Actual problem was likely a result of DST change not being written to HW, that
likewise could be reproduced, but requires more effort.)
Actual results:
The hardware clock remains at the set value, though system time is corrected.

Expected results:
Hardware clock adjusted to system time, or UTC if configured.

Additional info:

I only noticed this due to a sort of race condition, I have cacti polling from this machine on a one minute interval. chronyd starts before cron, but it did not complete the time adjustments before cron ran the poller script, which inserted a poller_lastrun value 45 minutes into the future into the cacti DB and stopping polling either until adjusted or 45 minutes had elapsed.

I looked for a chronyd file in /etc/sysconfig but it's use seems to have been depreciated when looking at rpm spec files and in it's systemd script so there seems to be no way to easily test changing it's startup options.

I installed adjtimex to see if it will be used, that is not clear in documentation I was able to locate, if it does perhaps this is just a packaging problem and adjtimex needs to be included when chronyd is installed?
Comment 1 Miroslav Lichvar 2012-12-13 04:16:49 EST
I'm assuming this is with the default chrony configuration, which uses the rtcsync directive. Please let me know if chrony is configured with the rtcdrift directive instead, that would be a different bug.

With rtcsync, chronyd only tells the kernel that the system clock is synchronized and it's up to the kernel to correct the RTC. Unfortunately, the kernel doesn't care about timezones or DST and it's not able the fix the one hour error. This used to be handled by synchronizing the RTC from system clock on every shutdown/reboot, but that was for some strange reasons removed. Please see the bug #816752.

adjtimex is a system call and also a package which uses the system call. chrony cares only about the system call, which is always present (it's in the kernel).

*** This bug has been marked as a duplicate of bug 816752 ***
Comment 2 Steve Tyler 2012-12-13 05:24:41 EST
The chronyd configuration file is /etc/chrony.conf.

4.2.41 rtcsync

Note You need to log in before you can comment on or make changes to this bug.