Bug 885770 - Chrony not always setting hw clock correctly
Summary: Chrony not always setting hw clock correctly
Keywords:
Status: CLOSED DUPLICATE of bug 816752
Alias: None
Product: Fedora
Classification: Fedora
Component: chrony
Version: 17
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-10 15:27 UTC by Bob Rentschler
Modified: 2012-12-13 10:24 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-12-13 09:16:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Bob Rentschler 2012-12-10 15:27:56 UTC
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): 
chrony-1.27-0.3.pre1.fc17.x86_64

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 09:16:49 UTC
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 10:24:41 UTC
The chronyd configuration file is /etc/chrony.conf.
http://chrony.tuxfamily.org/manual.html#Configuration-file

4.2.41 rtcsync
http://chrony.tuxfamily.org/manual.html#rtcsync-directive


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