Chrony has been working well for us (on Linux, where we use it)

October 30, 2019

We have a variety of machines around here that run NTP servers, for various reasons. In the beginning they all ran some version of the classic NTP daemon, NTPD, basically because that was your only option and was what everyone provided. Later, OpenBSD changed over to OpenNTPD and so our OpenBSD machines followed along as they were upgraded. Then various Linuxes started switching their default NTP daemon to chrony, and eventually that spread to our usage (first for me personally and then for our servers). These days, when we need to set up a NTP daemon on one of our Ubuntu machines, we reach for chrony. It's what we use on our Ubuntu fileservers and also on an additional machine that we use to provide time to firewalls that are on one of our isolated management subnets.

At the moment this means we have three different NTP daemon implementations running in our environment. An assortment of OpenBSD machines of various versions run various versions of OpenNTPD, a small number of CentOS 7 machines run NTPD version '4.2.6p5' (plus whatever modifications Red Hat has done), and a number of Ubuntu machines run chrony. This has given us some interesting cross comparisons of how all of these work for us in practice, and the quick summary is that chrony is the least troublesome of the three implementations.

Our experience with the CentOS 7 NTPD is that it takes a surprisingly long time after the daemon is started or restarted (including from a system reboot) for the daemon to declare that it has good time. Chrony seems to synchronize faster, or at least be more willing to declare that it has good time (since what we get to see is mostly what chrony reports through SNTP). Chrony also appears to update the system clock the most frequently out of these three NTP implementations, which turns out to sometimes matter for ntpdate.

(I don't want to draw any conclusions from our OpenNTPD experience, since our primary experience is with versions that are many years out of date by now.)

I do mildly wish that Linux distributions could agree on where to put chrony's configuration file; Ubuntu puts it in /etc/chrony, while Fedora just puts it in /etc. But this only affects me, since all of our servers with chrony are Ubuntu (although we may someday get some CentOS 8 servers, which will presumably follow Fedora here).

(Chrony also has the reassuring property that it will retry failed DNS lookups. Normally this is not an issue for us, but we've had two power failures this year where our internal DNS infrastructure wasn't working afterward until various things got fixed. Hopefully this isn't a concern for most people.)

Comments on this page:

By bureado at 2019-12-09 16:17:22:

Thoughts on systemd-timesyncd? I was under the impression that some distros were starting to take that direction, particularly in virtualized scenarios...

By hobbs at 2020-05-15 02:52:20:

@cks: Ubuntu is following Debian convention here, which basically says that a package can have one top-level thing under /etc: either that's one file (ideally /etc/packagename.conf) or it's one directory (/etc/packagename/) with any amount of stuff under it. Chrony has 'chrony.keys' as well as 'chrony.conf' so it gets the directory treatment.

@bureado: systemd-timesyncd is nearer to an SNTP client than a NTP client. It tries to do some of the things that a real NTP client should do, but it doesn't do them well. I don't recommend running it anywhere.

Written on 30 October 2019.
« Netplan's interface naming and issues with it
Some thoughts on the pragmatics of classifying phish spam as malware »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Oct 30 23:20:17 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.