2

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:

  1. Running hwclock --set --date="$(magically-get-correct-time)"; hwclock -s just before Chrony does its job. Problem is that magically-get-correct-time still 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.

  2. Using ntpdate just 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[696]: 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

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
darque
  • 123
  • 1
  • 3
  • Some users might also want to look at the `makestep` setting (e.g., [`makestep 1 -1`](https://serverfault.com/a/933794/73591)). – basic6 Oct 03 '18 at 15:33

1 Answers1

4

Use initstepslew as shown in the documentation.

For example:

initstepslew 30 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org

And replace the batteries...

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940