If ntpd is running, ntpdate should never run - doing so causes clock
jumps. In Trusty, /etc/network/if-up.d/ntpdate actually stops ntpd so
ntpdate can run. Debian jessie doesn't do this, so if this was from
upstream, it's been fixed.
>From /etc/network/if-up.d/ntpdate:
-
if [ -e
* Disclaimer: The functionality of this program is now available in the
ntpd program. See the -q command line option in the ntpd - Network Time
Protocol (NTP) daemon page. After a suitable period of mourning, the
ntpdate program is to be retired from this distribution [1]. This page
was last
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: ntp (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1278359
Regarding the choice between ntp and ntpdate, I suspect that ntpdate is
a smaller package then ntp. Even if configurable as client, ntp still
also is a server package. I do not know for sure but this might be the
reason behind the use of ntpdate.
To raise the sync frequency to several times a day
I agree.
Regarding the aspect that most systems will be booted only once a day or less
it will probably affect only a few people as it is.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
I cannot see how making time sync calls even more sparse would not cause
even more drift.
ntpdate is obsolete. I am not even sure why we still deploy it instead
of ntp. Inertia, perhaps?
But this would not solve your issue: the replacement, be it NTP or
openntpd, or whatever, still needs to keep
Thank you for taking the time to report this bug and helping to make
Ubuntu better.
I recently dealt with this area of ntpdate's operation.
On systems that have a hardware clock this is not nessesary, causeing
unnessesary traffic and load on ntp servers.
Can you quantify this, please? I
