The solution suggested in comment #36 works for me, ntpd is running after reboot. Actually I did not create ntpdate_bak in the directory, I simply inserted the exit 0 statement in the script. ========= To resolve the bug ========= I suggest if-up.d/ntpdate is removed from the system. ========= Moreover I suggest ntpd to be started with option -g. ========= Moreover I suggest a surveillance task (cronjob) for ntpd and hwclock update. And here are my arguments for the suggested solution:
I tried to find a real world situation where if-up.d/ntpdate makes any sense. I could not find one. Apparently it is difficult to pin point the precise cause of the ntpdate/ntpd interference or at least it is difficult to decide how to correct it. This script seems to be the only one using deprecated ntpdate. If script removal is considered too aggressive just disable it by inserting the exit 0 statement. I assume that upon shut down the hwclock is set to the latest state of the the system clock. Upon (re)boot the time value kept in the hwclock is brought back to the systemclock. This should guarantee that the system clock even very early in the boot sequence is pretty close to the perfect value. There is no need to leap the time gap as is done by deprecated ntpdate. During normal operation there is no need either - ntpdate never does a better job than ntpd when called in a system that runs ntpd. Ironically if-up.d/ntpdate would bring up ntpd which is not fair in a system that was configured for some other method to maintain a proper clock setting. The only situation where I can imagine a leap in setting the time is desirable is when the hwclock fails. This is a bad situation that I had on a machine shut down for a long time and the battery of the hwclock had stopped to provide power. Unless the -g option is used ntpd dies because the time difference is larger than the panic threshold. The -g option does no harm in normal situations but allows for one big step in time to cope with that situation. If e.g. ntpd is configured with just one time resource and that resource suddenly changes by more that the panic threshold than ntpd would die. To cope with such a situation a surveillance mechanism (e.g. cronjob) should be in place including a restart mechanism. A cronjob could also update the hwclock on a regular (monthly) basis. Some systems really are up for years and then the hwclock might be off by more than the panic threshhold (1000") if there is an irregular shutdown (loss of power) . -- 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/1577596 Title: ntpd not started when using ntpdate Status in init-system-helpers package in Ubuntu: Confirmed Status in ntp package in Ubuntu: Won't Fix 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 fails. If I replace /etc/init.d/ntp with a file containing only the following, systemd won't try to start it automatically at boot: #!/bin/sh ### BEGIN INIT INFO # Provides: ntp # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 1 # Short-Description: Start NTP daemon ### END INIT INFO 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 * timesyncd.conf:#NTP= timesyncd.conf:#FallbackNTP=ntp.ubuntu.com /lib/systemd# grep -R ntp * system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/ntpd system/systemd-timesyncd.service.d/disable-with-time-daemon.conf:ConditionFileIsExecutable=!/usr/sbin/openntpd 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: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1577596/+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
