ntpdate remains after upgrade to Xenial and causes problems with ntpd

[Matt LaPlante]

I have a system running 16.04.1 with multiple interfaces configured via /etc/network/interfaces. Following a restart, ntpd will often be found not running, despite being installed and configured.

syslog suggests ntpd is being repeatedly stopped and restarted within seconds.

Dec 13 20:23:17 mail ntpd[4031]: ntpd 4.2.8p4@1.3265-o Wed Oct 5 12:34:45 UTC 2016 (1): Starting
Dec 13 20:23:17 mail ntpd[4031]: ntpd 4.2.8p4@1.3265-o Wed Oct 5 12:34:45 UTC 2016 (1): Starting
Dec 13 20:23:17 mail ntpd[4031]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:113
Dec 13 20:23:17 mail ntpd[4031]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:113
Dec 13 20:23:17 mail ntpd[4034]: proto: precision = 0.105 usec (-23)
Dec 13 20:23:17 mail ntpd[4034]: unable to bind to wildcard address :: - another process may be running - EXITING
Dec 13 20:23:17 mail ntpd[4034]: proto: precision = 0.105 usec (-23)
Dec 13 20:23:17 mail ntpd[4034]: unable to bind to wildcard address :: - another process may be running - EXITING
Dec 13 20:23:18 mail ntp[4119]: * Stopping NTP server ntpd
Dec 13 20:23:18 mail ntp[4119]: * Stopping NTP server ntpd
Dec 13 20:23:18 mail ntp[4183]: * Starting NTP server ntpd
Dec 13 20:23:18 mail ntp[4183]: * Starting NTP server ntpd
Dec 13 20:23:18 mail ntpd[4193]: ntpd 4.2.8p4@1.3265-o Wed Oct 5 12:34:45 UTC 2016 (1): Starting
Dec 13 20:23:18 mail ntpd[4193]: ntpd 4.2.8p4@1.3265-o Wed Oct 5 12:34:45 UTC 2016 (1): Starting
Dec 13 20:23:18 mail ntpd[4193]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:113
Dec 13 20:23:18 mail ntpd[4193]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:113
Dec 13 20:23:18 mail ntpd[4195]: proto: precision = 0.065 usec (-24)
Dec 13 20:23:18 mail ntpd[4195]: proto: precision = 0.065 usec (-24)
Dec 13 20:23:18 mail ntpd[4195]: unable to bind to wildcard address :: - another process may be running - EXITING
Dec 13 20:23:18 mail ntpd[4195]: unable to bind to wildcard address :: - another process may be running - EXITING

My current assumption is that this is the work of /etc/network/if-up.d/ntpdate being run on several interfaces nearly simultaneously. The rapid stop/start cycle of the daemon appears to trip up the port binding, and eventually cause ntpd to become unhappy and wind up stopped.

Manually restarting ntpd (or even running /etc/network/if-up.d/ntpdate) outside of interface up/down time properly brings up ntpd. It doesn't appear to be a configuration issue as such.

Further, running /etc/network/if-up.d/ntpdate from bash several times in rapid succession also produces the 'missing ntpd' behavior, outside of the context of any interface activity.

[Joshua Powers (powersj)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Do you want NTP to listen on all addresses? That is not typically what someone will want. That is why there is the -I option (e.g. -I 127.0.0.1) that can be added to the command line in /etc/default/ntp to listen on a specific port or address.

Since there isn't enough information in your report to differentiate between a local configuration problem and a bug in Ubuntu, I'm marking this bug as Incomplete. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New.

If indeed this is a local configuration problem, you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community

[Joshua Powers (powersj)]

My information may be out of date, instead of using -I you may also try adding the following:

interface ignore wildcard
interface listen 127.0.0.1
interface listen ::1

[Matt LaPlante (cybrmatt)]

I actually think I gave a fairly thorough description of the problem and it has nothing to do with ntpd configuration. I even said specifically that I can manually start/stop ntpd and it works - configuration valid and operational.

The problem is /etc/network/if-up.d/ntpdate starting and stopping the daemon in rapid succession when multiple interfaces come up. This causes binding conflicts and often ntpd will wind up down as a result.

Reproduction is fairly easy: Just run /etc/network/if-up.d/ntpdate several times in rapid succession and see what happens.

[Robie Basak (racb)]

Please see: https://lists.ubuntu.com/archives/ubuntu-devel/2016-August/039484.html

Summary: in Ubuntu, we don't expect to use ntpdate any more. We're leaving bugs in ntpdate packaging behind, on the basis that ntpdate no longer needs to be installed by default.

Can you fix the problem by removing the ntpdate package?

Is there anything unique about your configuration that means that you're hitting this bug "by default"? How is it that you have ntpdate installed in the first place? If you installed it yourself, why did you install it?

[Matt LaPlante (cybrmatt)]

Removing ntpdate should remove the if-up script, so I imagine that would "resolve" the bug by way of workaround.

The hosts in question were upgraded from prior LTS, so they would have inherited ntpdate from there. I wasn't aware of the changes to sunset it in the current release.

[Robie Basak (racb)]

> The hosts in question were upgraded from prior LTS, so they would have inherited ntpdate from there.

Thanks. We didn't have it removed for upgraders, so I guess that's not happening by any other mechanism. I'm not sure we should do that either. The only packaging mechanisms I can think of would also mean that users of newer releases wouldn't be able to install ntpdate at all, and I don't think we want that.

I'll rename this bug to track your specific case ("I upgraded from an older release, ntpdate remained, and it causes trouble"). If anyone else hits this, please mark yourself as affected by this bug (link for logged in users near the top left of the page). If your scenario is essentially the same but under a difference circumstance, please note it here.

[Christian Ehrhardt  (paelzer)]

Hi,
coming back to this cleaning bugs that were dormant for too long - sorry for that!
I realized that I tackled this in bug 1593907 which is currently on the way through SRU process.
If you can once it is accepted you can certainly help there with verifications.
Marking this one a dup to track all in one place.