chrony

chrony keeps a system clock synchronised with time servers. It has largely replaced ntpd on Linux distributions, and it is the sort of infrastructure that receives no attention at all until it fails.

Why time synchronisation is load-bearing

Clock skew breaks things in ways that rarely point at the clock:

  • Certificate validation fails. A certificate valid from a time in the future is rejected, and TLS errors do not mention the clock.
  • Kerberos and similar protocols refuse to authenticate beyond a small skew tolerance, by design.
  • Distributed logs become unorderable. Correlating events across hosts in a SIEM assumes comparable timestamps; skew between hosts makes a causal sequence look reordered, and an incident timeline reconstructed from skewed logs is worse than none.
  • Scheduled jobs drift or double-fire when a clock is stepped backwards.

The last point is why the manner of correction matters as much as the correction. chrony slews the clock — speeding it up or slowing it down until it converges — rather than stepping it, so time never goes backwards. Code that assumes monotonically increasing time is everywhere, and a backward step breaks it in ways that are almost impossible to diagnose after the fact.

What it does better than ntpd

Intermittent connectivity. chrony was designed for machines not permanently online. It maintains a model of the clock’s drift rate and can keep reasonable time while disconnected, then reconverge quickly. ntpd assumed constant connectivity and handled disconnection poorly.

Virtual machines. VM clocks are unreliable in a particular way: the hypervisor may suspend the guest, leaving it to resume with a clock that is simply wrong. chrony converges much faster after this, which matters given how much runs virtualised.

Faster initial sync, which matters at boot when services with certificate or authentication requirements start before time is correct.

Practical notes

Use several servers rather than one, so a single wrong source can be outvoted. A pool address supplies this.

The makestep directive permits stepping the clock for large initial offsets — sensible at boot, and worth constraining to the first few updates so it does not step a running system. chronyc tracking reports the current offset and drift, and is the first command when timestamps look wrong.

See also: systemd, rsyslog, and Linux administration in datacenters.