Bug 865916 - Please update chrony to sync hardware RTC as soon as a time fix has been made
Please update chrony to sync hardware RTC as soon as a time fix has been made
Status: CLOSED DUPLICATE of bug 816752
Product: Fedora
Classification: Fedora
Component: chrony (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-10-12 15:41 EDT by Lennart Poettering
Modified: 2012-10-15 04:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-10-15 04:46:35 EDT
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 Lennart Poettering 2012-10-12 15:41:17 EDT
In older Fedora versions, the system clock was synced down to the RTC at shutdown. We dropped this a while ago, since without knowledge that the system clock was accurate and in which mode the RTC clock is used (local or UTC) we shouldn't touch the RTC, and systemd generally does not have this knowledge.

Now, chrony is in a much better position to know when the system clock is accurate, as making sure of that is pretty much is job and since for that it implements NTP and includes code to deal with RTC skews. As the kernel already syncs minor clock changes on its own (via the 11min mode), we'd like to see chrony sync big time jumps (i.e. the initial clock jump if there is one) to the RTC as well, so that all bases are covered.

The are multiple ways to implement this:

a) I'd recommend simply patching the chrony C code to sync big time jumps down to the RTC device. This means that big jumps are immediately reflected in the hardware, and the time correction is not lost on power failure and similar occasion. This is the cleanest and most robust solution, in my opinion.

b) hwclock -w is invoked as part of the chrony unit files at the right point in time, i.e. after big time jumps. Alternatively via a cron job/timer unit, if that's desired.

c) hwclock -w is invoked at shutdown, but this has the negative impact that time correction is lost if power is turned off abruptly or the machine otherwise dies without a clean shutdown. This behaviour comes closest to the behaviour of old Fedora, but is probably the least desirable.

Either way this logic should only be done if chrony is installed and enabled as only then the system clock is known to be accurate enough. If a) is implemented this will be the case automatically. If b)/c) is implement a nice way would be to pull the sync units if chrony is enabled, i.e. via Also= in the [Install] section of the units.

Please add a C patch to chrony for this (a), or alternatively package unit files invoking hwclock for this (b/c).

Comment 1 Lennart Poettering 2012-10-12 15:46:02 EDT
Note that this bug is probably not of highest priority since this currently only affects systems with clocks off for more than 30min, and an easy work-around exists (hwclock -w).
Comment 2 Miroslav Lichvar 2012-10-15 04:46:35 EDT
I think we need to reach a conclusion in the bug #816752, before we start patching every program which can set the system clock.

Some points:
- chrony includes a code which tracks the RTC drift, but it obviously can't work when the kernel 11-minute sync is enabled
- with the 11-minute mode, setting the RTC only once on the first sync may be not enough if there are long periods of time when the computer is not synced via NTP
- chrony needs to be told whether the RTC is in LOCAL or UTC too
- the RTC tracking feature in chrony is considered obsolete, since hwclock does a better job at this as its measurements include the time when the machine was powered down and the drift was different due to lower temperature of the crystal
- there is probably a better place for the hwclock -w service or cron job than every package which can set the clock

*** This bug has been marked as a duplicate of bug 816752 ***

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