On Thu, 23 Mar 2023 12:12:04 +0000 Richard Lewis <richard.lewis.deb...@googlemail.com> wrote: > Presumably the release notes should also say that most people should > consider systemd-timesyncd as this is priority:standard (since at > least buster, but i dont remember seeing this in release notes then)? > - i assume the idea is that if you dont have any special needs beyond > "set the clock" should use systemd-timesyncd, And people who need > extra features (like running their own ntp server) should install > ntpsec / chrony / opennntpd ?
Recommending timesyncd as an NTP client to replace ntpd would not be a good idea, especially if you consider the default configuration using servers from pool.ntp.org. The pool is very robust as a whole, but individual servers cannot be relied on. They are run by volunteers. Some are well maintained, some are not. Occasionally, servers drift away or step to a distant past or future, e.g. due to GPS firmware bugs. The pool monitoring system detects such servers and quickly removes them from the pool DNS, but simple clients like timesyncd cannot recover from that. Once they got the address from DNS, they will follow the server for as long as it claims to be synchronized, no matter how wrong it is. A full-featured NTP client is needed to detect and replace falsetickers. With timesyncd the only option is to restart the service when you notice the clock is wrong. I've seen many times users complaining about that and getting this advice over the years. timesyncd needs to be configured with a reliable server to work well. Canonical maintains their own NTP servers and uses them by default in Ubuntu. That makes senses. Debian uses pool.ntp.org, so it should recommend a proper NTP client for a reliable service.
