I will look more closely at what is going on, James. On your last comment: yes, this is a known, huh, issue/limitation: if there is no name server resolution available, then fully-qualified hostnames (like ntp.ubuntu.com, or pool.ntp.org, etc) will not get resolved -- after all, they do depend on having access to a NS. Usually, when synchronisation is critical, NTP should be set with an IP address, not a FQHN.
But, once bound to a working interface, NTP should eventually be able to access a NS, and synchronise.
Right now it is starting to look like we have two different issues here:
(1) when NTP is installed, network-manager should not call ntpdate;
(2) NTP cannot bind to an interface that is not available during startup (this one is a bit more convoluted, methinks: if n-m is the one setting up any, and all network interfaces, then it seems NTP should not be started until n-m successfully brings up such an interface).
I will look more closely at what is going on, James. On your last comment: yes, this is a known, huh, issue/limitation: if there is no name server resolution available, then fully-qualified hostnames (like ntp.ubuntu.com, or pool.ntp.org, etc) will not get resolved -- after all, they do depend on having access to a NS. Usually, when synchronisation is critical, NTP should be set with an IP address, not a FQHN.
But, once bound to a working interface, NTP should eventually be able to access a NS, and synchronise.
Right now it is starting to look like we have two different issues here:
(1) when NTP is installed, network-manager should not call ntpdate;
(2) NTP cannot bind to an interface that is not available during startup (this one is a bit more convoluted, methinks: if n-m is the one setting up any, and all network interfaces, then it seems NTP should not be started until n-m successfully brings up such an interface).
Do you agree?