Heretic! :-) You miss the joy of having ntp offset graphs for all your systems :-)

A cronjob every hour is a fine option, but we've got a couple of cases where we wanted more.

Our mail system comprises of about 50 servers in various roles interacting with each other and other internet mail servers. We don't want them to be pretty close with each other but a big offset away from what other mail servers believe is the correct time. We want each and every one of them to be ntp synced when talking to any other server. We want all Received: lines to be correct in the mail headers.

Knowing that all our servers are ntp synced gives me the pleasure to suggest "Use telnet mailgate.forthnet.gr 25 to find the time difference between us." when I contact someone else regarding say an abuse incident, to calculate timezone differences in logs.

We've also got some systems running on a Microsoft Hyper-V cluster which is terrible beyond any imagination in providing time sync services to linux systems. hwclock and system time drifted apart more than 3 minutes in less than 60 seconds. A cronjob running ntpdate every minute on those systems couldn't keep up with the actual drift on the system. ntpd is the only option to save those poor VMs running there (with tinker panic 0).

Jumping back in time is something many daemons don't handle well. They should, but they don't. Until recently, many Go programs couldn't handle that because Go didn't expose the monotonic clock. Internally, Go was using it but any external use of a clock to compute delta could lead to a negative value, a edge case rarely tested. This could lead to an incorrect stat or to a crash. See the Cloudflare bug.

Moreover, the Linux kernel keeps a tab to know if time is synchronized with a time daemon. This is exposed to userland and some program may wait for the time to be trustworthy to do something. The only example on the top of my head is hwclock which is not that important (it won't save time if kernel says time is not synchronized).

Instead you should have almost all of your machines set their time from a trusted upstream source on boot and every so often afterward (once an hour is often convenient).

Indeed, and you're pretty much describing an SNTP client such as systemd-timesyncd.

It is better that they all be wrong together than some of them be right and others be wrong

But hardware clocks can vary wildly in accuracy so I don’t see how relying on those helps you keep your fleet closely synchronised. Also, if a machine can be wrong out of step with the fleet because it fail to sync from the time server, why would this apply to ntpd but not a periodic ntpdate?

Basically it seems to me like you’re arguing against the typical default configuration of NTP dæmons of smearing clock changes over time and trying to be intelligent about the server pool, rather than against running an NTP dæmon per se.

I suppose the argument from your point of view is that once you have turned these features off, an NTP dæmon isn’t doing much else than a periodic ntpdate. But without making that point explicitly, you’ll get people like me and my fellow commenters quibbling with you. 😊

If you're doing periodic synchronization, the big question is not how accurate the system is over the long term but how accurate it is between those synchronizations; that drift is your maximum deviation from true time (and twice it is your worst case deviation from each other). My belief and evidence so far is that drift is low for reasonably decent servers in our environment, and probably for reasonably decent servers in general.

The traditional 'out of sync' problem with ntpd is not that a machine's time is off because it failed to sync to the time server, but that it's failed to sync with the time server because its initial time is so far off that ntpd didn't consider any time sources as valid. Ntpdate fixes this because you can tell ntpdate 'sync the time to upstream no matter how far off it is'. You can probably tell your NTP daemon to do this too, with the right configuration, but it's likely not the default and it may not be spelled out explicitly in the documentation.

(Traditionally an NTP daemon sees its job as 'maintain good time', which includes distrusting bad sources, while ntpdate and friends have the job of 'set the time to that of an upstream source'.)

If you have to carefully build a NTP daemon configuration to override a collection of defaults, you're going through a lot of effort to get more or less what you can get from ntpdate for free (well, for a little script in /etc/cron.hourly). And you still have the issue of what happens if the NTP daemon dies or stops working right, which can happen.

(There are also potential issues with a daemon if you, say, change the DNS for your time servers so they have different IPs. Will the running NTP daemons automatically re-check DNS and get the new IPs, or will some of them carry on with the old ones and perhaps stop being able to talk to anything? With a cron job, you know that ntpdate is re-resolving the hostnames every time it runs.)

What about shutting up bad clients? It's a lot less likely that you can persistently stop an errant SNTP client which is doing its thing from cron. To this day home routers still come hardcoded with particular NTP server names (rather than using a CNAME pool for the router vendor).

Also VMs are notorious for having clocks that drift so they are desirable to discipline regularly.

Here I'm only considering the case where all the machines involved are on your own network(s) and under your control. So if there's an errant client banging away from cron, you can go and fix it (or perhaps block it at some internal firewall).

I will admit that VMs are a hard problem, especially if you're running OSes that aren't carefully set up to take their time from the VM hypervisor (which stock ones won't be, because hardware clocks are traditionally not accurate enough).

Ah understood. There's one more side issue - some one shot time synchronization setups have a habit of looking up the time each time the DHCP lease is renewed (I'm looking at you systemd-timesyncd) . This can lead to unnecessarily frequent clock synchronizations when connecting to DHCP servers with tiny lease times (e.g. five minutes) but there's definitely a convenience to such setups (they correct time the moment the network is up)...