ntpd handles dynamic network configurations just fine, as does timesyncd; ntpdate never handled dynamic network configurations, and I don't think it makes sense to work around that with scripts when real NTP daemons do the right thing automatically. ntpdate (and other software like tlsdate) makes sense as a standalone tool, but invoking it automatically seems less sensible. (Plus, it makes more sense to continuously keep time up to date, rather than only at boot or network change.)
I understand at least part of this argument. It is reasonable for a modern PC to keep the clock accurate, by running a lightweight daemon.
Suppose network configuration is dynamic, and the NTP daemon is not integrated with the specific network configuration system. It only uses general purpose interfaces (including some Linux kernel interfaces). What is required to make this work?
Historically it is common to integrate specifically by having the network system run a script. But I searched and I think systemd-networkd does not implement any script hooks. If you look at the link above, it at least shows the developers do not like script hooks very much.
This question is a bit hypothetical - I have a similar question in mind, so I wondered how this is handled for NTP.
If the initial attempt to synchronize to NTP is judged to have failed, I assume a simple approach e.g. retrying after one hour would be sufficient.[*]
a) My question is how you detect when you should try to start with. I think this might vary a bit depending what server(s) you configured the NTP client to use. E.g.
- Has a DNS server been configured yet?
- Do we have a route configured to any of the DNS servers yet? (A default route is fine, but not necessarily available in all cases).
- Are the DNS servers for this interface configured and reachable yet? (E.g. when using systemd-networkd's support for non-global DNS names on multiple interfaces).
- Is the NTP server hostname resolved without using a DNS server, e.g. using /etc/hosts or MDNS?
- Do we have a route configured to the NTP server yet?
b) We're supposed to be a bit polite to pool.ntp.org servers. So I guess we don't want to simply retry immediately after every possible network configuration event?
c) In order to detect when systemd-resolved (or NetworkManager+dnsmasq, or ...) has configured a DNS server, you would need specific integration with that network configuration system, right? In the case of systemd-networkd, the ntp client would have to integrate using a DBus interface, right?
[*] Because often the network connection is relatively simple. You connect directly to a single router, which usually has a working connection to the global internet and DNS. Or the network is more complex internally, but the individual components do not fail/recover very often. Usually we are not trying use to a mesh network that only has internet connectivity 50% of the time, for example.
