[Bug 1577596] Re: ntpd not started when using ntpdate

Paul Donohue ubuntu at PaulSD.com
Sat May 7 22:36:03 UTC 2016

Aha! I've found the issue.

/etc/network/if-up.d/ntpdate is called when each network interface comes
up.  This happens before network.target is reached, so it happens before
ntp.service would normally be automatically started by systemd.

/etc/network/if-up.d/ntpdate calls `invoke-rc.d ntp stop`, then it runs
ntpdate, then it calls `invoke-rc.d ntp start`.

`invoke-rc.d ntp stop` runs `systemctl stop ntp.service`, which causes
systemd to cancel the ntp.service start task that was automatically
scheduled to happen after network.target.

`invoke-rc.d ntp start` calls `/sbin/runlevel` to determine the current
runlevel so that it can verify the existence of a /etc/rc?.d/S??ntp
symlink for the current runlevel.  However, `/sbin/runlevel` returns
"unknown" because systemd has not reached multi-user.target yet.
Therefore, invoke-rc.d determines that the appropriate /etc/rc?.d/S??ntp
symlink does not exist, so it does not call `systemctl start
ntp.service` to start ntp.

Changing /etc/network/if-up.d/ntpdate so that it calls `systemctl start
ntp.service` instead of `invoke-rc.d ntp start` fixes the problem.

However, I think I would consider this to be a bug in invoke-rc.d and
not ntpdate, since invoke-rc.d simply does not work properly when
systemd is being used and invoke-rc.d is called at boot time.  At the
very least, I would think invoke-rc.d should document that this is
unsupported, and it should detect and report this condition if invoke-
rc.d is called at boot time (rather than just silently failing).

** Also affects: init-system-helpers (Ubuntu)
   Importance: Undecided
       Status: New

You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to init-system-helpers 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:

More information about the foundations-bugs mailing list