I've switched from ntpd to chrony as my NTP daemon

November 15, 2017

I've been running some version of NTP(D) on my machines for a very long time now. In the early 1990s the University of Toronto was lucky enough to have Dennis Fergusson, who was very interested in time keeping and wrote a version of ntpd; I caught my interest in NTP from the general UofT Unix sysadmin environment at the time and kept it ever since.

When I first vaguely noticed chrony, it was on my Fedora laptop; way back in Fedora 11, Fedora switched to chrony by default. The release notes at the time made it sound like chrony was just a client and was focused on laptops and other frequently disconnected machines, so I didn't pay much attention to it. I let a Fedora upgrade switch my laptop over, because why not, but otherwise I kept on running ntpd without thinking twice. Over time this got a little bit more annoying on my desktop machines, because Fedora kept trying to switch over and I'd keep having to reverse that and block chrony every few Fedora version upgrades so that I'd keep running my old faithful setup.

I'm not sure what caused me to take an actual look at chrony, but in late September I did just that. This time around I read the chrony web pages and thus discovered that chrony is a full featured NTP daemon, just like ntpd. That definitely made me look at chrony in a new light, as did chrony's comparison page. I'm occasionally given to sudden impulses, so I decided to switch over more or less on the spot; my logs say that I shut down ntpd and started chrony on my office workstation shortly before noon on September 25th (and then on my home machine the next morning). This turned out to be interesting timing, as shortly afterward the Core Infrastructure Initiative released Securing Network Time, where chrony came out by far the best of the three NTP implementations that were evaluated.

The CII article indirectly explains why I was willing to consider switching. There's a quiet schism going on in the NTP world, with a group of people forking the main NTP code to develop 'NTPSec'; infosec people whose views I respect are quite down on the result, and I haven't been terribly impressed by what I've read about the project. At the same time, the NTP code itself is acknowledged to be old and crusty, which is not a great thing for either security or its long term future. Once I found out that chrony was a full featured NTP daemon written from scratch, with modern code and active maintenance, switching seemed like not a bad idea.

(I'd previously checked out Poul-Henning Kamp's quite interesting Ntimed as another potential ntpd replacement, but sadly it went dormant.)

I'm broadly pleased with the result of switching. Chrony has been easier to configure and the result mostly works the way I want. The daemon seems to work just as well as ntpd and my time stays synchronized, just as before. There are some things from ntpq that I miss, especially the ability to easily see what my time sources are themselves synchronized to, but I'll survive. On the positive side, chrony has some useful additional features for my home machine, such as the explicit ability to tell the daemon that we're about to go offline.

We don't have many machines that run full time NTP daemons, but in the future I'm going to propose setting up such machines with chrony instead of ntpd if chrony is packaged for their OS. At this point, sadly I have a lot more trust in ongoing maintenance and support for chrony than I do for NTP.

There's a part of me that's a little bit sad about this because, as mentioned, I have been running ntpd for a very long time. Even though I'm still keeping up with time keeping, switching to something else feels like the end of an era. It's one more link to history quietly slipping away.


Comments on this page:

We don't have many machines that run full time NTP daemons

You mean you don't have many machines that run full time NTP daemons and service others as a time source, right ?

How do you keep time synchronized in your systems if not by running ntpd? an ntpdate cronjob?

We run ntpd on all our machines, but started switching to chrony when RHEL7 came along. Same feelings..

By nobody at 2017-11-15 10:44:18:

For client machine you can use systemd-timesyncd

Back when I tried it, sometimes before 2011, offline support was, ehm, theoretical - there were scripts that were SUPPOSED to automatically tell chrony about it, but in practice they worked maybe 10% of the time and chrony was left thinking the servers were ~100% unreachable and therefore discarded all of them; other than that (it has been fixed, hasn't it?) it was fairly pleasant.

The simplest to set up is definitely openntpd(*), but 1. it implements only a subset of ntp; 2. it may or may not be too spartan depending on taste; 3. some web pages claim the non-openbsd version is abandoned - this has not been true for the last couple of years.

(*) example config file:

#listen on *
servers pool.ntp.org
By Dan.Astoorian at 2017-11-16 10:49:20:

I stumbled upon chrony by accident upon discovering it was the CentOS 7 default. (Actually, upon trying to install and enable ntpd on CentOS 7 and finding that chrony was stopping ntpd.)

A little more reading, and I discovered chrony solved a problem I was having at the time with the Raspberry Pis we use for digital signage: if the network was not connected when the Pi booted, ntpd could not resolve the names of its time servers, and would never synchronize at all, ever. Given that the Pi has no hardware clock, this was a problem. (The Raspbian mechanism which is supposed to start/restart ntpd when the network is brought up did not work as intended for some reason.)

chrony, on the other hand, will keep trying to resolve the names until it succeeds.

If one's desire is specifically for a rewrite of ntpd, NTPsec is definitely not what you're looking for, at least not yet. That does not mean NTPsec is without value.

The NTPsec project has done what the NTP project should have been doing all along: They significantly cleaned up the existing code base, most notably by throwing away 75% of the code, which was ancient and no longer useful.

In saying "should", I'm making no judgement of the NTP project here. If they were lacking in funding and/or developer time, it is completely understandable how this happened. I know this from lots of personal experience on other projects.

The NTPsec project, or at least ESR on its behalf, is quite open about trying to satisfy a set of users who don't want radical change, but want an evolution of the daemon they already know.

They have done a ground-up rewrite of the client tools into Python, while preserving the vast majority of the tools' user interface.

A ground-up rewrite of ntpd may very well achieve a more secure result than a cleanup (and probably an eventual transition to Go or Rust). That rewrite already existed in chronyd (and others), but ntpd is still in massive use. To me, that suggests that the NTPsec approach might be worth trying.

Written on 15 November 2017.
« We may have reached a point where (new) ARM servers will just work for Linux
I think you should mostly not run NTP daemons on your machines »

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

Last modified: Wed Nov 15 01:53:41 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.