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.

  1. Has a DNS server been configured yet?
  2. 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).
  3. 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).
  4. Is the NTP server hostname resolved without using a DNS server, e.g. using /etc/hosts or MDNS?
  5. 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.



The quote mentions ntpd, the reference NTP daemon. The full message includes a list of if-up.d script hooks in Debian. There is no hook script for ntpd (nor chrony). The only NTP-related scripts are for ntpdate and openntpd.

If ntpd does not receive a response from a server, I believe it will resend a packet 64 seconds later.

What is the minimum interval between retries to an unresponsive NTP server?

EDIT: however after a number of failed retries, the retry interval will be increased, eventually to 1024 seconds. (Both values are configurable, but those are the defaults).

The ntpd documentation also claims some timings were chosen "to allow a modem call to complete". That sounds like ntpd was already designed so it could support network connections that are made and lost dynamically, without needing to be explicitly notified. However, the relevant section appears to be misleading. And considering the maximum retry interval above, I think the default settings would not work in every possible case.


In contrast, other references suggest ntp was not well-suited for dialup use, partly due to the DNS question. And that chrony works better, but it is designed to use script hooks. The chrony-3.4 package in Fedora Linux 29 includes a hook script, /etc/NetworkManager/dispatcher.d/20-chrony.


systemd-timesyncd integrates with systemd-networkd (and nothing else). Currently it appears to use an undocumented interface.

When systemd-timesyncd thinks it is online and it fails to "connect", it appears to retry every 30 seconds.

systemd-networkd initially had no DBus interface. Or rather, the one it had was not considered to be ready yet.

It already appears to be possible to run hook scripts using systemd-networkd semantics. Although it would not be a good idea to automatically run all the if-up.d hook scripts, due to some differences in the available semantics. (As argued in the Debian bug thread linked in the question). See:

With systemd-networkd, perform an action upon network configuration change

[*] It also makes it sound like the design of ntpd is ancient, so it might not perfectly fit modern considerations. E.g. for a small battery-powered tablet device.[**] Would you want to retry every 64 seconds, when the server is not responding? EDIT: the system does not retry every 64 seconds indefinitely. After a certain period of unreachability, the poll interval is increased. ("The poll() routine includes a feature that backs off the poll interval if the server becomes unreachable...")

[**] As I understand it, "mobile"-class devices are designed so they can be left overnight and suspend most of the system, with the possible exception of the network hardware (which can respond to ARP without waking the CPU; perhaps it can rotate encryption keys e.g. for WPA as well).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.