Thank you for taking the time to report this bug and helping to make Ubuntu better.
I've confirmed that the issue is as you describe in Xenial. Trusty pre- dates the change to locking in ntp.if-up, so is consistent. Zesty is also consistent in using flock in both places, as is Artful. So this bug affects only Xenial. In order to understand the importance of this bug, please could you explain why you're using both ntp and ntpdate? ntpdate isn't installed by default on Xenial, and shouldn't be required in the normal case because ntp defaults to "-g". So you could work around this bug by just removing the ntpdate package. Is there a particular reason that this won't work in your case? ** Also affects: ntp (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: ntp (Ubuntu) Status: New => Fix Released ** Changed in: ntp (Ubuntu Xenial) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1706818 Title: mismatched file locking since 1:4.2.8p4+dfsg-3ubuntu1 causes race leaving ntp dead on reboot Status in ntp package in Ubuntu: Fix Released Status in ntp source package in Xenial: Triaged Status in ntp package in Debian: Unknown Bug description: ntpdate and ntp conflict on the NTP well-known-socket. If ntp and ntpdate 1:4.2.8p4+dfsg-3ubuntu5.5 are installed on Xenial, and there are 2 static interfaces configured, most often we find that ntpd is not running after a reboot. When the ntp service is started by systemd, ntp fails to bind the NTP socket because ntpdate is running in the background. It's intended that ntp and ntpdate try to avoid this conflict with a lock file, but the locking mechanism was changed in ntpdate.if-up (from lockfile to flock), but it was not changed in ntp.init. Previously the file locking prevented ntp from trying to start when ntpdate was running. Not any more. Having multiple interfaces causes a much longer period of the socket being unavailable, because the 2 ntpdate processes will get serialized by the lock, while the ntp service is looking for a different lock, so it just plows right in. Attempts by netdate.if-up to stop and start ntp seem to overlap and when the final start is invoked, systemd seems to thing ntp is already running, though it has failed. In 1:4.2.8p4+dfsg-3ubuntu1 the following change was made: debian/ntpdate.if-up: Drop lockfile mechanism as upstream is using flock now. Looks like corresponds to rev 371 of debian/ntpdate.if-up from upstream. This change diverged locking between ntpdate.if-up and ntp.init. This was rectified in rev 451 of ntp.init, to use compatible locking, but that doesn't appear in the Ubuntu version. System Information: lsb_release -rd: Description: Ubuntu 16.04.2 LTS Release: 16.04 apt-cache policy ntpdate: ntpdate: Installed: 1:4.2.8p4+dfsg-3ubuntu5.5 Candidate: 1:4.2.8p4+dfsg-3ubuntu5.5 Version table: *** 1:4.2.8p4+dfsg-3ubuntu5.5 100 100 /var/lib/dpkg/status apt-cache policy ntp: ntp: Installed: 1:4.2.8p4+dfsg-3ubuntu5.5 Candidate: 1:4.2.8p4+dfsg-3ubuntu5.5 Version table: *** 1:4.2.8p4+dfsg-3ubuntu5.5 100 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1706818/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp