@Robie - IIRC Paul wants to use it as "remote ntp check" which actually
should be done via sntp but that binary was unavailable until artful and
the fix doesn't fit an SRU (bug 1604010).
@Josh - just a day after your report the SRU completed that took out the old
locking and the silly unconditional restart from the ifup hooks. I'd hope
things should be much better for you now - could you please verify if that is
true for your scenario as well?
If not we have to search where the remaining issue comes from as the new
behavior should have ntp preferred to ntpdate and ntpdate being the one
rejected as ntp already has the port used.
If there is a window e.g. due to the many interfaces that you described - that
inverts that with ntpdate blocking ntp still that would have to be fixed.
** Changed in: ntp (Ubuntu Xenial)
Status: Triaged => Incomplete
--
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:
Incomplete
Status in ntp package in Debian:
Fix Released
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
