NTP servers from DHCP are not propagated to timesyncd

Updates version of the script.

I tried to reproduce this, to test the fix, but I am stuck trying to figure out how to manually set the ntp server. I can't see any difference between when the vm (with no network) has this /etc/NetworkManager/dispatcher.d/10-update-timesyncd file in place or not. I think that's good but maybe not so relevant without “seeing” the problem. I've been looking at the commands:
   ◇ systemctl status systemd-timesyncd
   ◇ timedatectl show
   ◇ timedatectl status
I believe timedatectl is the way a user would interact with timesyncd and there's a timedatectl command to set the time zone or even time, but nothing to set the server. So how the heck do you change the NTP server to something other than ntp.ubuntu.com?

The server is set via a configuration file. The default config file is /etc/systemd/timesyncd.conf and it can be overridden by dropping files in /etc/systemd/timesyncd.conf.d/.
There is a pool of free ntp servers available on https://www.ntppool.org/en/.

To test this fix you also need a DHCP server that returns NTP records.

With VMs, you can use dnsmasq to provide NTP records by changing the values in dnsmasq.conf
# Set the NTP time server addresses to 192.168.0.4 and 10.10.0.5
#dhcp-option=option:ntp-server,192.168.0.4,10.10.0.5

Or if you're using libvirt, edit the configuration with "virsh net-edit default" (or the name of the network your VMs are attached to) then pass the option directly to dnsmasq (cf https://libvirt.org/formatnetwork.html for reference)

The bug is assigned and targetted to focal, it's import for the LTS but we don't believe it should be a release issue for impish

@Seb this fix has to go to focal for a customer project and must land in the dev release first.

I've got this setup between two vms, where the server vm is hosting dnsmasq with ntp and the client synchronizes from the server (on a private network). This issue of the timesync conf needing to be updated exists in systemd-timesyncd too. But tackling the NetworkManager case as this is the customer issue.. we could put this fix in either networkd-dispatcher or network-manager. I've got a local build of network-manager that drops the file in place.. but needs to be tweaked.

Should the 10-update-timesyncd file be put in place by networkd-dispatcher or network-manager?

IMHO having the fix in network-dispatcher makes more sense.

There is also an additional requirement. The package must install successfully and replace an existing file that would have been created manually (we had to ship the file on the image for the customer since we don't have this fix in a package yet)

Here is a networkd-dispatcher fix:
https://launchpad.net/~hellsworth/+archive/ubuntu/networkd-dispatcher/+build/22316215

And here is a network-manager fix:
https://launchpad.net/~hellsworth/+archive/ubuntu/network-manager/+build/22316944

Both should work, so please test the networkd-dispatcher fix first and network-manager if needbe.

was the issue reported and discussed upstream yet? those scripts added to the package sound like downstream workaround we will have to carry and should be a backup plan if the issue can't be properly fixed upstream. And even if a distro hack makes sense it would be better to have it in Debian to reduce or maintainance

Status changed to 'Confirmed' because the bug affects multiple users.

Hi,
Here I found a better version of this script. It implements DHCPv6 and handles directory and file creation better f.ex when IF goes down.

https://roll.urown.net/desktop/network/time-sync.html

Unfortunately the variable $DHCP6_NTP_SERVERS is always empty in my case. Even I have correct NTP and SNTP server addresses in my DHCPv6 options. I checked them with Wireshark.

This issue is also present on Bionic. Is there a chance that the network manager would be fixed in Bionic, as part of Ubuntu Pro?