I can’t guarantee a sane real-time clock on some machines (the time might be wrong by hours, months or even years). Since I also have intermittent networking, I set up Chrony in the hopes it could fix the issue.
But it seems that Chrony wants to adjust the clock slowly over time, keeping the clock monotonic and without drastic changes. This is adequate when the drift is in the order of seconds, but simply isn’t a solution for my case (in my tests, it took hours to correct a 10 minutes drift). I disabled
maxupdateskew, by the way.
What I actually want is to make a big change early at boot (non-monotonic if time is set at future), accurate to the order of seconds or (even better) milliseconds, and after it is applied the ntp client is free to do its gradual adjustments. I supposed this was an important use case for ntp clients, specially for machines without an RTC, but I can’t find well supported solutions for this issue.
I have considered the following:
hwclock --set --date="$(magically-get-correct-time)"; hwclock -sjust before Chrony does its job. Problem is that
magically-get-correct-timestill have to gather over ntp or other service, and then I have to schedule Chrony to run after it succeeds.. this is tricky to do (like: what if this command fails because network is poor? This may quickly become complicated). Generally, this feels like duct-taping.
ntpdatejust before Chrony. Google tells this was suggested in some forums. I don’t know how well would this work, and also feels like duct tape. (also, ntpdate is reported to be deprecated)
Right now, what I am actually looking for is a way for solving this using only Chrony. What made me to think it might be able to solve it was page on the Fedora Wiki regarding Chrony as default NTP client. It claims:
after the initial synchronization the clock is never stepped, this is good for applications which need system time to be monotonic
For me, this suggests that during something called initial synchronization, Chrony may make non-monotonic stepping. Or so I hope. But on my installation, when it says
Feb 19 17:15:30 black chronyd: System clock wrong by -759.702379 seconds, adjustment started
It doesn’t jump to aggressively correct it ASAP; it instead spreads the change over hours, never making non-monotonic changes. So I don’t see any of this “initial synchronization” mentioned. And I haven’t been able to find out how to configure it to make any non-monotonic adjustment at all.
By the way, I am running Arch Linux with Chrony 1.27
initstepslew as shown in the documentation.
initstepslew 30 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
And replace the batteries…
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.