ntpdate startup routine prevents ntp service from launching up on Ubuntu 16.04 server on system boot

Bug #1593907 reported by igor on 2016-06-18
96
This bug affects 38 people
Affects Status Importance Assigned to Milestone
ntp (Ubuntu)
High
Christian Ehrhardt 
Trusty
High
Christian Ehrhardt 
Xenial
High
Christian Ehrhardt 
Yakkety
High
Christian Ehrhardt 
Zesty
High
Christian Ehrhardt 

Bug Description

[Impact]

 * Fixes several broken cases, those are:
 * Case 1 - ntp configured to drift time slowly, but time jumping
     - ntp is running and drifts time towards a target being way off
     - an interface comes up
     - stop ntpd
     - warp time via ntpdate-debian (static interfaces will even set -b)
     - (re-)start ntpd
     - if users relied on non-time warp they are now in trouble

 * Case 2 - ntp start/stop storms
     - ntpd comes up normally
     - the admin brings interfaces up/down rather often
     - ntp is restarted very very often due to this for no reason
     => reason for bugs like debian 823533

 * Case 3 - unintentional enablement of ntp
     - ntpd is installed but disabled (for whatever reason)
     - all is fine on any ifup/down
     - one installs ntpdate, maybe even without realizing due to a depends
     - now on the next ifup ntpd (or openntpd) will be started

 * Solution, drop the broken Delta

[Test Case]

 * Testing Case 2/3 as it is the easiest, case 1 needs a more complex
   setup to cause the time drift but otherwise works the same way.
   - install ntp and ntpdate
   - stop ntp
   - ifup/ifdown an interface multiple times; as simplification you can
     also call /etc/network/if-up.d/ntpdate directly (not that this
     spawns the change asnchronous and locks concurrency, so do that a
     few times over the time of a minute or so)
   - the service of ntp should still be stopped and not report plenty of
     restarts

[Regression Potential]

 * It improves a lot of cases (otherwise we wouldn't SRU), but there is
   one regression potential I can see:

   - users that relied on starting NTP later on after other interfaces
     got up due to that code in ntpdate which did that as a side effect.
     But that is outweigh by Case2/3 for the majority of users. And even
     Case1 only hits this potential regression on e.g. late network
     intialization, but in that case please remind that the default
     (systemd timedatectl) would handle that.

   - Since most users of ntp do not install ntpdate (which doesn't work
     when ntp is active) we should be rather safe to assume that almost
     no one should rely on that side effect.

   - Furthermore this is a Ubuntu Delta for very long, cause issues (see
     the references on the git commit) but never made it into Debian -
     in that sense another indicator it isn't an important delta to
     have.

[Other Info]

 * The original intention "what if net is available too late" fixed
   correctly would not be part of ntpdate, but ntp and additionally
   check if it is actually meant to be enabled - but I never seen/heard
   of any of it since systemd is around - maybe new ordering mostly
   avoids the original issue.

---

I've installed ntp service on the clean ubuntu 16.04 server system. Configured it. Checked that it works, but, after reboot, it doesn't start automatically.
When I check: 'systemctl is-enabled ntp', it shows enabled.
If I manually start it 'systemctl start ntp' it starts just fine and woks correctly,
but until I manually start it, 'systemctl status ntp' shows:

    Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
    Active: inactive (deadi)

Installed 1.29ubuntu2 version of init-systems-helper, but it didn't fix the problem.

Found a bugreport on ntpd package:

    https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1577596

led to solution that involves a change to be made in file:

    /etc/network/if-up.d/ntpdate

of ntpdate package

After changing from:
______________CODE_START______________

    invoke-rc.d --quiet $service stop >/dev/null 2>&1 || true

     # Avoid running more than one at a time
     flock -n /run/lock/ntpdate /usr/sbin/ntpdate-debian -s $OPTS 2>/dev/null || :

    invoke-rc.d --quiet $service start >/dev/null 2>&1 || true

______________CODE_END______________

to:
______________CODE_START______________

    systemctl --quiet stop $service.service >/dev/null 2>&1 || true

     # Avoid running more than one at a time
     flock -n /run/lock/ntpdate /usr/sbin/ntpdate-debian -s $OPTS 2>/dev/null || :

    systemctl --quiet start $service.service >/dev/null 2>&1 || true

______________CODE_END______________

ntpd service started launching on boot.

System Information:

  lsb_release -rd:

    Description: Ubuntu 16.04 LTS
    Release: 16.04

  apt-cache policy ntpdate:

    ntpdate:
      Установлен: 1:4.2.8p4+dfsg-3ubuntu5
      Кандидат: 1:4.2.8p4+dfsg-3ubuntu5
      Таблица версий:
     *** 1:4.2.8p4+dfsg-3ubuntu5 500
            500 http://ru.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
            100 /var/lib/dpkg/status

igor (igoryonya) on 2016-06-18
description: updated
description: updated
igor (igoryonya) on 2016-06-18
summary: ntpdate startup routine prevents ntp service from launching up on Ubuntu
- 16.04 server on system boot; manually starting ntp service works
+ 16.04 server on system boot; manually starting ntp service works: [FIX
+ in DESCRIPTION], just need to apply it and release a new version
igor (igoryonya) on 2016-06-18
description: updated
Joshua Powers (powersj) on 2017-06-12
Changed in ntp (Ubuntu):
importance: Undecided → High

Hi Igor, first of all I beg your pardon that this was dormant for so long - just too many issues to pick from and NTP was long neglected for having so many issues we didn't want Delta but Debian didn't update. After Stretch was released NTP moved again in Debian, so if we need/want to change there as well it seems better now.
Also part of this reluctance is due to systemd timedatectl >> ntpdate (deprecated and causing all kind of trouble) and such.
Anyway - time to tackle things - and thanks for your debugging and suggestion already!

The particular change you suggested moves it from SysV to systemd which is fine for Ubuntu, but might be an issue to Debian who still allow to switch to SysV.

To re-triage the current state I checked this out once more on Xenial (as reported) and Artful.
Both still run systemctl from the generated service based on sysV /etc/init.d/ntp.

Just installing NTP has a running service after install:
- On both releases a invoke-rc.d ntp stop stops it properly
- On both releases a invoke-rc.d ntp start starts it properly again
- Rebooting (without ntpdate installed yet) works just fine, service running

Installing ntpdate and retrying:
- after boot the service is up in xenial and artful
- On both releases a invoke-rc.d ntp stop stops it properly
- On both releases a invoke-rc.d ntp start starts it properly again

Weird, unable to confirm or reproduce your issue.
But I remember we discussed and changed things around there - (waking up my memory).
Checking the ifup hook confirmed that - the stop/start is gone anyway in the newer release.

... Yeah memory was right I fixed that in Artful on the merge because this thing was way more complex and error prone than its benefit - one can check details at [1].

I need to backport that to X/Y/Z - preparing for that now ...

[1]: https://git.launchpad.net/~usd-import-team/ubuntu/+source/ntp/commit/?id=943814aa43eb5915f4b643cd48061b3a7e4c75f8

Changed in ntp (Ubuntu):
status: Confirmed → Fix Released

With so much history, Trusty as well ...

Changed in ntp (Ubuntu Xenial):
status: New → Triaged
Changed in ntp (Ubuntu Yakkety):
status: New → Triaged
Changed in ntp (Ubuntu Zesty):
status: New → Triaged

Later to be combined in SRU Template Reasoning - snippest updated from my old commit log to be readable here in the bug:

Cases of the codepath (Ubuntu Delta) that we intent to remove:

    Case 1 - bug that it meant to fix initially:
     - ntpd comes up and can not find peers to associate with
     - an interface comes up
     - stop ntpd
     - sync time once with ntpdate-debian
     - (re-)start ntpd (now able to find its peers, but it will throw away what
       ntpdate just has set, so not worth)

    Case 2 - more common case:
     - ntpd comes up normally
     - the admin brings interfaces up/down rather often
     - ntp is restarted very very often due to this for no reason
     => That behavior is close to a bug on its own, which is the reason for
    bugs like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823533

    Case 3 - still more common
     - ntpd is installed but disabled (for whatever reason)
     - all is fine on any ifup/down
     - one installs ntpdate, maybe even without realizing due to a depends
     - now on the next ifup ntpd (or openntpd) will be started

By dropping this section we fix it for Case 2 and Case 3.
Users of Case 1 still have no impact - their call to ntpdate will refuse to change things as there is a running ntp.
Like:
$ /usr/sbin/ntpdate-debian
  20 Jun 08:02:32 ntpdate[519]: the NTP socket is in use, exiting
And as outlined in Case 1 the running ntp would resync over it anyway.
If there was nothing running at all - well then the sync works and things are fine still.

There is one regression potential I can see:

- users that relied on starting NTP later on after other interfaces got up due to that code in ntpdate which did that as a side effect. But that is outweigh by Case2/3 for the majority of users. And even Case1 only hits this potential regression on e.g. late network intialization, but in that case please remind that the default (systemd timedatectl) would handle that.

- Since most users of ntp do not install ntpdate (which doesn't work when ntp is active) we should be rather safe to assume that almost no one should rely on that side effect.

- Furthermore this is a Ubuntu Delta for very long, cause issues (see the references on the git commit) but never made it into Debian - in that sense another indicator it isn't an important delta to have.

Note: The original intention "what if net is available too late" fixed correctly would not be part of ntpdate, but ntp and additionally check if it is actually meant to be enabled.

Added SRU Template.

description: updated

Manual Tests on the issue complete, ppa fixes all known cases.
Now checking some regression tests ...

Changed in ntp (Ubuntu Xenial):
status: Triaged → In Progress
Changed in ntp (Ubuntu Yakkety):
status: Triaged → In Progress
Changed in ntp (Ubuntu Zesty):
status: Triaged → In Progress

Regression tests of https://git.launchpad.net/qa-regression-testing good as well.

Ok we have:
- complete SRU Template
- tests of the case itself from ppa's
- regression checks on all releases

That said pushing for SRU review.
For Trusty ubuntu-server-dev had no upload permissions yet - so I'm subscribing ~ubuntu-sponsors.

@Sponsors: for trusty if you could upload from [1] into Trusty-unapproved that would be very kind. You can do so via Bileto "publish" or by fetching the debdiff on that page whatever you prefer.

[1]: https://bileto.ubuntu.com/#/ticket/2829

Changed in ntp (Ubuntu Trusty):
status: New → In Progress
Changed in ntp (Ubuntu):
assignee: nobody → ChristianEhrhardt (paelzer)
Changed in ntp (Ubuntu Trusty):
assignee: nobody → ChristianEhrhardt (paelzer)
Changed in ntp (Ubuntu Xenial):
assignee: nobody → ChristianEhrhardt (paelzer)
Changed in ntp (Ubuntu Yakkety):
assignee: nobody → ChristianEhrhardt (paelzer)
Changed in ntp (Ubuntu Zesty):
assignee: nobody → ChristianEhrhardt (paelzer)
Adam Conrad (adconrad) wrote :

So, the one regression I see possible here is on machines with lousy/broken clocks at boot time. If you start ntpd with a clock too far in the past/future, it'll either give up and exit (if VERY far off) or start a drift that could take hours/days to correct. If you remove the restarting around ntpdate, ntpdate will refuse to fix the clock (due to the socket being in use), and you're stuck either with a dead ntpd, or a drift of doom.

Adam Conrad (adconrad) wrote :

Of course, this would be adding complexity instead of removing it, but it might be worth doing an "ntpdate -q" first, parsing the output, and if the offset is "large enough" (whatever that might be), do the stop/ntpdate/start dance, else exit.

Hi Adam,
thanks for thinking through the potential regressions with me here.
I think the one you mentioned on top is not a real one.
Let me explain why:

There is:
root@artful-test:~# cat /etc/default/ntp
NTPD_OPTS='-g'

And -g is defined as:

Defined as:
-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic
       threshold, which is 1000 s by default.
       This option allows the time to be set to any value without restriction; however, this can
       happen only once. If the threshold is exceeded after that, ntpd will exit with a
       message to the system log. This option can be used with the -q and -x options.

I checked how much that is true backward in releases, but it seems safe.
root@trusty-test:~# cat /etc/default/ntp
NTPD_OPTS='-g'

So in the default setup ntp will do the adjustment and not refuse/drift-of-doom.
If a user explicitly changed that option we actually fix another issue with the SRU here.
The user that dropped the -g would expect not to do the major adjustment on his ntp, but the stop/ntpdate/start loop would do so.

Please get in touch with me again if you do not agree.

That said - please reconsider for Trusty sponsoring and SRU acceptance

Directly attaching the trusty debdiff for sponsoring instead of forcing a sponsor through bileto.

As discussed on IRC:
- the default of -g is also going along with a default of jumping any time >a threshhold ONCE.
  -x can change that

To be sure I tested that on Xenial:
$ timedatectl
      Local time: Thu 2017-06-29 15:58:29 UTC
  Universal time: Thu 2017-06-29 15:58:29 UTC
        RTC time: Thu 2017-06-29 15:58:29
       Time zone: Etc/UTC (UTC, +0000)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

ubuntu@x-ntp-skip-test:~$ sudo timedatectl set-ntp false
ubuntu@x-ntp-skip-test:~$ sudo timedatectl set-time 01:02:03
ubuntu@x-ntp-skip-test:~$ timedatectl
      Local time: Thu 2017-06-29 01:02:05 UTC
  Universal time: Thu 2017-06-29 01:02:05 UTC
        RTC time: Thu 2017-06-29 01:02:05
       Time zone: Etc/UTC (UTC, +0000)
 Network time on: no
NTP synchronized: no
 RTC in local TZ: no

$ sudo add-apt-repository ppa:ci-train-ppa-service/2828
[...]
$ sudo apt install ntp
[...]
$ systemctl status ntp
● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
   Active: active (running) since Thu 2017-06-29 01:04:36 UTC; 14h ago
[...]
$ timedatectl
      Local time: Thu 2017-06-29 16:02:50 UTC
  Universal time: Thu 2017-06-29 16:02:50 UTC
        RTC time: Thu 2017-06-29 01:05:33

Watch the time the service was started and the time it has now.
It it did warp once initially as it is intended.

If I skew the time later it will not instant-reset again.

Then I dropped the -g from the options to be sure it is this what makes it work and it did not time warp anymore as expected - the offset is known but not solved.
$ ntpq -p
     remote refid st t when poll reach delay offset jitter
==============================================================================
[...]
 golf.zq1.de 192.53.103.103 2 u 51 64 1 13.436 5456358 5456358
And afterwards the service goes active (exited) as according to the -g doc the daemon gives up without -g on too big time deltas.

That said I summarize - good to go on sponsoring trusty and with the SRUs in that regard.

Nish Aravamudan (nacc) wrote :

Sponsored the upload to Trusty.

On Wed, Jul 5, 2017 at 7:19 PM, Nish Aravamudan <email address hidden> wrote:
> Sponsored the upload to Trusty.

Thanks but just as of tonight it seems a security update burned all my uploads versions.
This seems to have waited too long in SRU-review&sponsoring, need to reroll and ping here again then.

Burned versions (please reject in SRU queue)
- T: 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11
- X: 1:4.2.8p4+dfsg-3ubuntu5.5
- Y: 1:4.2.8p8+dfsg-1ubuntu2.1
- Z: 1:4.2.8p9+dfsg-2ubuntu1.1

New uploads are prepared and checked for T/X/Y/Z.
- T: ntp_4.2.6.p5+dfsg-3ubuntu2.14.04.12
- X: ntp_4.2.8p4+dfsg-3ubuntu5.6
- Y: ntp_4.2.8p8+dfsg-1ubuntu2.2
- Z: ntp_4.2.8p9+dfsg-2ubuntu1.1

I uploaded those I can (X/Y/Z) and they are in the SRU unapproved queue again.
I also refreshed the debdiff for Trusty attached in this update - please sponsor and consider with the others as SRU.

Version typo, the new one in Zesty unapproved is of course bumped to ntp_4.2.8p9+dfsg-2ubuntu1.2

Robie Basak (racb) wrote :

I'm going to sponsor Christian's Trusty upload without review, wearing my DMB hat. It's a technicality that he can't upload it; he already has DMB approval to do so.

Hello igor, or anyone else affected,

Accepted ntp into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ntp/1:4.2.6.p5+dfsg-3ubuntu2.14.04.12 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ntp (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-trusty
Changed in ntp (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed-xenial
Robie Basak (racb) wrote :

Hello igor, or anyone else affected,

Accepted ntp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ntp/1:4.2.8p4+dfsg-3ubuntu5.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ntp (Ubuntu Yakkety):
status: In Progress → Fix Committed
tags: added: verification-needed-yakkety
Robie Basak (racb) wrote :

Hello igor, or anyone else affected,

Accepted ntp into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ntp/1:4.2.8p8+dfsg-1ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-yakkety to verification-done-yakkety. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-yakkety. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ntp (Ubuntu Zesty):
status: In Progress → Fix Committed
tags: added: verification-needed-zesty
Robie Basak (racb) wrote :

Hello igor, or anyone else affected,

Accepted ntp into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ntp/1:4.2.8p9+dfsg-2ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Please do note that in addtion to all we did before we also checked one more corner case before movign to proposed. The one that ntp was meant to be active, but came up before e.g. ppp0 and due to that can't resolve peers. It turns out ntp relaized networks that get enable later and triggers its resolver - so the stop/start on ifup hook wasn't needed to keep that working.

Doing SRU verifications now ...

Verified on all four targeted releases:
- the hook does no more start a disabled ntp
- the hook multiple times does no more is a thundering herd of stop/start ntp
- ntpdate does not stop ntp, warp time, start ntp (might warp back if configured differently)
- ntpdate no clashing with a (potentially) running ntp is not fatal (there is a log entry of the ntp socket being already in use, but that is correct - one could precheck if running and avoid even trying, but much better than restarting or timewarping)

No regression seen yet, so hopefully all is good. Setting verifications to done.
Still if some of the affected could test in addition to that that would be great.

tags: added: verification-done verification-done-trusty verification-done-xenial verification-done-yakkety verification-done-zesty
removed: verification-needed verification-needed-trusty verification-needed-xenial verification-needed-yakkety verification-needed-zesty
Changed in ntp (Ubuntu Trusty):
importance: Undecided → High
Changed in ntp (Ubuntu Xenial):
importance: Undecided → High
Changed in ntp (Ubuntu Yakkety):
importance: Undecided → High
Changed in ntp (Ubuntu Zesty):
importance: Undecided → High
Brian Murray (brian-murray) wrote :

Lets let this bake for another week to see if we can get some testing from those affected.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ntp - 1:4.2.8p8+dfsg-1ubuntu2.2

---------------
ntp (1:4.2.8p8+dfsg-1ubuntu2.2) yakkety; urgency=medium

  * debian/ntpdate.if-up: Drop delta to stop/start service around ntpdate
    updates - fixes ntp restart storms due to network changes, fixes
    accidential start of ntp, avoids issues of ntpdate jumping too far while
    running ntp was supposed to drift (LP: #1593907)

 -- Christian Ehrhardt <email address hidden> Fri, 07 Jul 2017 07:58:18 +0200

Changed in ntp (Ubuntu Yakkety):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for ntp has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

summary: ntpdate startup routine prevents ntp service from launching up on Ubuntu
- 16.04 server on system boot; manually starting ntp service works: [FIX
- in DESCRIPTION], just need to apply it and release a new version
+ 16.04 server on system boot
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ntp - 1:4.2.8p4+dfsg-3ubuntu5.6

---------------
ntp (1:4.2.8p4+dfsg-3ubuntu5.6) xenial; urgency=medium

  * debian/ntpdate.if-up: Drop delta to stop/start service around ntpdate
    updates - fixes ntp restart storms due to network changes, fixes
    accidential start of ntp, avoids issues of ntpdate jumping too far while
    running ntp was supposed to drift (LP: #1593907)

 -- Christian Ehrhardt <email address hidden> Fri, 07 Jul 2017 07:56:45 +0200

Changed in ntp (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ntp - 1:4.2.8p9+dfsg-2ubuntu1.2

---------------
ntp (1:4.2.8p9+dfsg-2ubuntu1.2) zesty; urgency=medium

  * debian/ntpdate.if-up: Drop delta to stop/start service around ntpdate
    updates - fixes ntp restart storms due to network changes, fixes
    accidential start of ntp, avoids issues of ntpdate jumping too far while
    running ntp was supposed to drift (LP: #1593907)

 -- Christian Ehrhardt <email address hidden> Fri, 07 Jul 2017 07:59:52 +0200

Changed in ntp (Ubuntu Zesty):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ntp - 1:4.2.6.p5+dfsg-3ubuntu2.14.04.12

---------------
ntp (1:4.2.6.p5+dfsg-3ubuntu2.14.04.12) trusty; urgency=medium

  * debian/ntpdate.if-up: Drop delta to stop/start service around ntpdate
    updates - fixes ntp restart storms due to network changes, fixes
    accidential start of ntp, avoids issues of ntpdate jumping too far while
    running ntp was supposed to drift (LP: #1593907)

 -- Christian Ehrhardt <email address hidden> Fri, 07 Jul 2017 07:53:16 +0200

Changed in ntp (Ubuntu Trusty):
status: Fix Committed → Fix Released
Mian (hou-m) on 2017-09-05
Changed in ntp (Ubuntu Xenial):
milestone: none → xenial-updates
milestone: xenial-updates → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers