While debugging a clock issue I noticed that my RTC was out of sync.
Clearly this should be impossible, since any NTP implementation will
periodically set the hardware clock to the system clock. Except, for
reasons that I entirely fail to grok[1], systemd-timesyncd.
So I am disabling that pile of junk and replacing it with an NTP
implementation that actually meets the bare requirements of an NTP
implantation. I could be convinced to replace this with OpenNTPD.
Existing users should first disable the pile of junk before upgrading to
chrony:
$ sudo timedatectl set-ntp false
Chrony is started in offline mode, and is told to attempt to communicate
with the pools via a NetworkManager dispatcher. I considered plugging
this in to nmtrust, as part of my campaign to minimize traffic on
untrusted networks, but this seems likely to be overkill. I could be
convinced otherwise.
Chrony's dial-up configuration[2] is attractive and may be worth
implementing. My inclination is that in the current setup with the
normal NetworkManager dispatcher, most spark clients will be online
frequently enough that setting system time by tracking RTC drift is
unnecessary. If the dispatcher is changed to plug into nmtrust, the
drift-tracking configuration becomes much more attractive -- when on the
road, a machine may not connect to a trusted network for weeks. I could
be convinced otherwise.
Chrony is configured to use the same Arch vendor pools as were used by
systemd-timesyncd. I am unsure if we should specify these by IP rather
than hostname, if there are better or smarter defaults we should
provide, or if it worth making the pools a configuration option.
[1]: https://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html
[2]: https://chrony.tuxfamily.org/manual.html#Dial_002dup-overview
