[Touch-packages] [Bug 1593907] Re: 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

[Launchpad Bug Tracker]

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   Fri, 07 Jul
2017 07:58:18 +0200

** Changed in: ntp (Ubuntu Yakkety)
   Status: Fix Committed => Fix Released

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  Fix Committed
Status in ntp source package in Xenial:
  Fix Committed
Status in ntp source package in Yakkety:
  Fix Released
Status in ntp source package in Zesty:
  Fix Committed

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:
  

[Touch-packages] [Bug 1593907] Re: 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

[Brian Murray]

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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  Fix Committed
Status in ntp source package in Xenial:
  Fix Committed
Status in ntp source package in Yakkety:
  Fix Committed
Status in ntp source package in Zesty:
  Fix Committed

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 

[Touch-packages] [Bug 1593907] Re: 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

[Mathew Hodson]

** 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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  Fix Committed
Status in ntp source package in Xenial:
  Fix Committed
Status in ntp source package in Yakkety:
  Fix Committed
Status in ntp source package in Zesty:
  Fix Committed

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

  

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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 removed: verification-needed verification-needed-trusty 
verification-needed-xenial verification-needed-yakkety verification-needed-zesty
** Tags added: verification-done verification-done-trusty 
verification-done-xenial verification-done-yakkety verification-done-zesty

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  Fix Committed
Status in ntp source package in Xenial:
  Fix Committed
Status in ntp source package in Yakkety:
  Fix Committed
Status in ntp source package in Zesty:
  Fix Committed

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)
  

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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 ...

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  Fix Committed
Status in ntp source package in Xenial:
  Fix Committed
Status in ntp source package in Yakkety:
  Fix Committed
Status in ntp source package in Zesty:
  Fix Committed

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 

[Touch-packages] [Bug 1593907] Re: 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

[Robie Basak]

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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  Fix Committed
Status in ntp source package in Xenial:
  Fix Committed
Status in ntp source package in Yakkety:
  Fix Committed
Status in ntp source package in Zesty:
  Fix Committed

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, 

[Touch-packages] [Bug 1593907] Re: 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

[Robie Basak]

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.

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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.

** Patch added: "trusty_ntp_bug_refreshed_1593907.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+attachment/4910711/+files/trusty_ntp_bug_refreshed_1593907.debdiff

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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:

  

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

On Wed, Jul 5, 2017 at 7:19 PM, Nish Aravamudan  
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, need to reroll and 
ping here again then.

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 || 

[Touch-packages] [Bug 1593907] Re: 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

[Nish Aravamudan]

Sponsored the upload to Trusty.

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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, +)
 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, +)
 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   641   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.

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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: 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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

** Patch added: "trusty_ntp_bug_1593907.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+attachment/4905387/+files/trusty_ntp_bug_1593907.debdiff

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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

  

[Touch-packages] [Bug 1593907] Re: 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

[Adam Conrad]

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.

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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:
  

[Touch-packages] [Bug 1593907] Re: 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

[Adam Conrad]

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.

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

** Changed in: ntp (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: ntp (Ubuntu)
 Assignee: (unassigned) => ChristianEhrhardt (paelzer)

** Changed in: ntp (Ubuntu Trusty)
 Assignee: (unassigned) => ChristianEhrhardt (paelzer)

** Changed in: ntp (Ubuntu Xenial)
 Assignee: (unassigned) => ChristianEhrhardt (paelzer)

** Changed in: ntp (Ubuntu Yakkety)
 Assignee: (unassigned) => ChristianEhrhardt (paelzer)

** Changed in: ntp (Ubuntu Zesty)
 Assignee: (unassigned) => ChristianEhrhardt (paelzer)

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  In Progress
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[Robie Basak]

** Also affects: ntp (Ubuntu Trusty)
   Importance: Undecided
   Status: New

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  New
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  New
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Trusty:
  New
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  In Progress
Status in ntp source package in Yakkety:
  In Progress
Status in ntp source package in Zesty:
  In Progress

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

  

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

Added SRU Template.

** Description changed:

+ [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 

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

PPAs ready for testing
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2828
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2829

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Triaged
Status in ntp source package in Yakkety:
  Triaged
Status in ntp source package in Zesty:
  Triaged

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
   

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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

** Bug watch added: Debian Bug tracker #823533
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823533

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Triaged
Status in ntp source package in Yakkety:
  Triaged
Status in ntp source package in Zesty:
  Triaged

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+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

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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.

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Triaged
Status in ntp source package in Yakkety:
  Triaged
Status in ntp source package in Zesty:
  Triaged

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+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

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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.

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Triaged
Status in ntp source package in Yakkety:
  Triaged
Status in ntp source package in Zesty:
  Triaged

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+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

[Touch-packages] [Bug 1593907] Re: 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

[ChristianEhrhardt]

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

** Also affects: ntp (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: ntp (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: ntp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Triaged
Status in ntp source package in Yakkety:
  Triaged
Status in ntp source package in Zesty:
  Triaged

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+subscriptions

[Touch-packages] [Bug 1593907] Re: 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

[Joshua Powers]

** Changed in: ntp (Ubuntu)
   Importance: Undecided => High

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Confirmed

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+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

[Touch-packages] [Bug 1593907] Re: 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

[Launchpad Bug Tracker]

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
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1593907

Title:
  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

Status in ntp package in Ubuntu:
  Confirmed

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+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

[Touch-packages] [Bug 1593907] Re: 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

[igor]

** Description changed:

  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)
  
- found bugreport on ntpd package:
+ 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

-- 
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/1593907

Title:
  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

Status in ntp package in Ubuntu:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1593907/+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