On Thu, May 05, 2016 at 01:44:06PM -0500, Christian Ehrhardt wrote: Hi Christian,
thanks for bringing this up. > While these days the systemd based timesync* tools are doing most of the > work there is still a lot of buzz around the automated ntpdate on ifup > being good/bad for various reasons. > > I'll try to to summarize the outcome of multiple discussions and bugs > around this that I recently passed and propose a solution. I think we even need a few more changes around here. First of all, we need to change the actual binary for a one-shot time sync from the long deprecated ntpdate to sntp. If we use sntp with the default configuration it uses an unpriviledged port, which should not race the startup of ntpd anymore. So we could get rid of all the locking. I've posted a mail regarding this on the mailing list a couple of months ago. https://lists.alioth.debian.org/pipermail/pkg-ntp-maintainers/2017-October/004850.html Third, I think a major issue is the package "ntpdate" both shipping the ntpdate binary (which one might want to use for debugging or because you just don't know sntp) and the ifup hooks, which simply do not work well with a lot of use cases. I'm pretty sure that most installations of ntpdate do not need it. I'm therefor proposing a complete rewrite - new package sntp-hooks - depends on sntp, ships hooks for ifupdown and possibly others (like NetworkManager or systemd-network or whatever Ubuntu is doing now) - executes the actual sntp synchronisation non-blocking, possibly with a one-shot systemd unit using --no-block when systemd is running - make ntpdate depend on sntp-hooks and rm_conffile all installed hooks So if you don't want hooks you just don't install sntp-hooks. The package sntp-hooks could additionally ship an /etc/default file to change behaviour. I have attempted to spin up some patches for this lately, but ran out of time. Is this something you could agree on Ubuntu-side? Bernhard
