I'm seeing same behavior as Alex where failure of ntpdate is preventing
ntpd from starting.  ntpdate is logging same message indicating failure
due to name resolution (Bind not running yet at boot):

Sep 16 10:40:09 scorpion ntpdate[1033]: name server cannot be used:
Temporary failure in name resolution (-3)

The script /etc/network/if-up.d/ntpdate does attempt to stop any running
ntp service prior to running ntpdate but then exits without restarting
ntp if ntpdate-debian fails.

I modified /etc/network/if-up.d/ntpdate to only log a message and exit
as a workaround and ntpd now starts at boot.

I'm still a bit puzzled why ntpd doesn't attempt to start after
/etc/network/if-up.d/ntpdate fails (multiple times in my case due to
multiple interfaces on host).  When /etc/network/if-up.d/ntpdate
runs/fails, there is no log message from ntp indicating it tried to
start (neither before nor after ntpdate fails).  However, after applying
my workaround, the log message for ntp service is one second after last
run of /etc/network/if-up.d/ntpdate.  I would have thought that the
failure of ntpdate would not prevent the later startup of ntp.  I'm
guessing that /etc/network/if-up.d/ntpdate initiates a stop in parallel
to systemd start of ntpd before it logs anything to syslog.

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.

  ntpd not started when using ntpdate

Status in init-system-helpers package in Ubuntu:
Status in ntp package in Ubuntu:

Bug description:
  After updating from 14.04 to 16.04 on a number of my systems, ntpd no
  longer starts at boot on any of those systems.

  `systemctl status ntp` shows:
     ntp.service - LSB: Start NTP daemon
     Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd-sysv-generator(8)
  May 02 19:10:14 host systemd[1]: Stopped LSB: Start NTP daemon.
  May 02 19:10:17 host systemd[1]: Stopped LSB: Start NTP daemon.

  Manually starting it using `systemctl start ntp` works fine.  However,
  systemd does not seem to want to start it automatically at boot time.

  As best as I can tell based on trial and error, there is something
  special about the combination of the service being named "ntp.service"
  and the service depending on network.target.  However, I haven't been
  able to identify exactly what is causing this.

  If I copy the init script to any other name, everything works fine:
  cp /etc/init.d/ntp /etc/init.d/ntpd
  Edit /etc/init.d/ntpd and change "Provides: ntp" to "Provides: ntpd"
  systemctl enable ntpd
  # After a reboot, ntpd.service is started, but ntp.service is not.

  If I remove "$network" from the "# Required-Start: $network $remote_fs
  $syslog" line in /etc/init.d/ntp, then systemd starts it automatically
  ... But of course it is started before the network comes up, so it

  If I replace /etc/init.d/ntp with a file containing only the following, 
systemd won't try to start it automatically at boot:
  # Provides: ntp
  # Required-Start: $network
  # Required-Stop: $network
  # Default-Start: 2 3 4 5
  # Default-Stop: 1
  # Short-Description: Start NTP daemon
  echo "script was run" >> /ntp.log

  If I rename that same dummy script to /etc/init.d/ntp2, it is started
  automatically at boot.

  However, grepping the systemd source code and my systemd config files for ntp 
doesn't seem to find anything that might cause this behavior:
  /etc/systemd# grep -iR ntp *
  /lib/systemd# grep -R ntp *
  Binary file systemd-networkd matches
  Binary file systemd-timedated matches
  Binary file systemd-timesyncd matches

  What else can I do to debug this further?

To manage notifications about this bug go to:

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

Reply via email to