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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577596 Title: ntpd not started when using ntpdate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1577596/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
