[Touch-packages] [Bug 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[David Britton]

** No longer affects: init-system-helpers (Ubuntu Bionic)

** No longer affects: init-system-helpers (Ubuntu Artful)

** No longer affects: init-system-helpers (Ubuntu Zesty)

** No longer affects: init-system-helpers (Ubuntu Xenial)

** Changed in: init-system-helpers (Ubuntu)
   Status: Confirmed => Opinion

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  Opinion
Status in pacemaker package in Ubuntu:
  Fix Released
Status in pacemaker source package in Xenial:
  Fix Released
Status in pacemaker source package in Zesty:
  Fix Released
Status in pacemaker source package in Artful:
  Fix Released
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Greg Lutostanski]

Confirmed with Drew that this bug has not been hit since the pacemaker
fix released.

Can remove field-high team, but keep for the discussion on init-system-
helpers.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  Confirmed
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  Confirmed
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  Confirmed
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  Confirmed
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Drew Freiberger]

>From a high level, it appears that invoke-rc.d script used for
compatibility falls back to checking for /etc/rcX.d symlinks for a
"policy" check if there is no $POLICYHELPER installed.  Perhaps the
actual shortcoming is not having the policy-rc.d installed to prefer
systemd over init.d on Xenial.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  Confirmed
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  Confirmed
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  Confirmed
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  Confirmed
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Rafael David Tinoco]

Is systemd's sysv-generator prioritized over regular systemd unit files
? My question raises from this fix. It looks like unit files were
automatically created because of the existence of the wrong LSB
parameters in init files - by the generator - but at the same time
Xenial should be using systemd unit files instead (as they are present
in this package).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  Confirmed
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  Confirmed
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  Confirmed
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  Confirmed
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: init-system-helpers (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  Confirmed
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  Confirmed
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  Confirmed
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  Confirmed
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: init-system-helpers (Ubuntu Zesty)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  Confirmed
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  Confirmed
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  Confirmed
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  Confirmed
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: init-system-helpers (Ubuntu Artful)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  Confirmed
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  Confirmed
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  Confirmed
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  Confirmed
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: init-system-helpers (Ubuntu Xenial)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  Confirmed
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  Confirmed
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  Confirmed
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  Confirmed
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  Confirmed
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Drew Freiberger]

re: init-system-helpers, I noticed the oddity of the init script on a
systemd system as well and found that there's a systemd hack in /lib/lsb
/init-functions.d/40-systemd that allows for multi-startup
compatibility.  I believe invoke-rc.d should check systemd
"enabled/disabled" state instead of just the S/K links in /etc/rcX.d.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Ryan Beisner]

** Tags added: uosci

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Ubuntu Foundations Team Bug Bot]

** Tags added: patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Launchpad Bug Tracker]

This bug was fixed in the package pacemaker - 1.1.14-2ubuntu1.3

---
pacemaker (1.1.14-2ubuntu1.3) xenial; urgency=medium

  * Fix default start/stop levels for init scripts, ensuring that
running pacemaker daemons are restarted after package upgrades
(LP: #1727063):
- d/p/Enable-the-init-scripts-on-multi-user-runlevels.patch: Cherry
  picked fix from later package versions.

 -- James Page   Wed, 25 Oct 2017 10:04:30 +0100

** Changed in: pacemaker (Ubuntu Xenial)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Andy Whitcroft]

Did some touch testing in a VM and confirmed that the 1.2 package loses
its daemons on any kind of reconfigured.  This behaviour is rectified
with the 1.3 package.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Fix Released
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

Also validated that the update fixes an existing machine with the 1.2
update on it (with pacemaker services not running).

Pacemaker started after the update.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[Edward Hope-Morley]

Tested proposed package upgrade and works for me -
http://pastebin.ubuntu.com/25815820/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

Testing from security-proposed PPA:

Broken install (dpkg-reconfigure pacemaker already run, daemons
stopped):  Packages updated and pacemaker daemon restarted by postinst:
OK

Running install (pacemaker daemons running prior to pkg upgrade):
Packages update, pacemaker daemon stop prior to unpack and restarted by
postinst: OK

>From my perspective the update looks good - but would appreciate a
second pair of eyes on this one.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

Also tested proposed fix on a three unit gnocchi HA deployment; all
pacemaker updates applied and restarted pacemaker postinst as desired.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

Updates building in:

  https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

** Description changed:

  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.
  
  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker
  
  pacemaker daemons will not be restarted.
  
  [Regression Potential]
- TBC as not quite sure where the fix for this is.
+ Minimal, earlier and later versions provide the defaults in the lsb header.
  
  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).
  
  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.
  
  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.
  
  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)
  
  I have not checked whether this affects trusty environments.
  
  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop entries.
  
  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

Tested OK (pacemaker was restarted after upgrade)

Uploaded to unapproved queue for SRU Team review - I'd suggest we
fasttrack this ASAP into -updates and -security to catch auto updates
for those systems not already updated.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  Minimal, earlier and later versions provide the defaults in the lsb header.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

Doing some testing via:

  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3010

before upload to xenial-proposed; not that the act of fixing this
problem will in itself cause the pacemaker daemons to be started on
upgrade.  However it won't be auto-applied on a default install (unlike
the security update that caused the original issue).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  TBC as not quite sure where the fix for this is.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

Proposed update for xenial

** Patch added: "pacemaker.debdiff"
   
https://bugs.launchpad.net/ubuntu/zesty/+source/pacemaker/+bug/1727063/+attachment/4993845/+files/pacemaker.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  TBC as not quite sure where the fix for this is.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

Actually this only impacts Xenial; Debian carried a patch from:

pacemaker (1.1.15~rc3-1) unstable; urgency=medium

  [ Christoph Berg ]
  * [23ee108] libcrmservice3.symbols: Exclude systemd symbol on non-linux
  * [41dea05] Fix time formatting on x32
  * [533c5cc] Fix FTBFS on GNU Hurd

  [ Arturo Borrero Gonzalez ]
  * [698053d] d/tests/control: add isolation-container restriction

  [ Ferenc Wágner ]
  * [065159d] New patch Enable-the-init-scripts-on-multi-user-runlevels.patch
  * [7a5008b] New patch Make-the-asciidoc-documentation-reproducible.patch
  * [08a4162] New patch Add-remote_fs-dependencies-to-the-init-scripts.patch
  * [7a65d2c] New upstream release (1.1.15~rc1)
  * [dd9f5f4] Remove upstreamed patches, refresh the rest
  * [0cdd116] Update symbol files
  * [3de7a21] New patch Add-documentation-URIs-to-the-service-files.patch
  * [9faaa02] Move documentation generators into Build-Depends-Indep
  * [9362a46] Move documentation into /usr/share/doc/pacemaker
  * [64c0e84] Move misc documentation files into the pacemaker-doc package
  * [837e74d] New patch Read-default-files-in-pacemaker.service.patch
  * [72fef80] New upstream release (1.1.15~rc2)
  * [69ee575] Remove patch included in 1.1.15~rc2
  * [46dce98] Also add documentation URI to our version of crm_mon.service
  * [8c25aff] New patch to avoid using WIFCONTINUED entirely
  * [a28e0ae] New upstream release (1.1.15~rc3)
  * [a8976fe] Remove freshly upstreamed patches, refresh the rest

 -- Ferenc Wágner   Sat, 28 May 2016 22:28:49 +0200


Which re-enables the default runlevels.

** Changed in: pacemaker (Ubuntu Bionic)
   Status: Triaged => Fix Released

** Changed in: pacemaker (Ubuntu Artful)
   Status: Triaged => Fix Released

** Changed in: pacemaker (Ubuntu Zesty)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Fix Released
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Fix Released
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Fix Released
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  TBC as not quite sure where the fix for this is.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage

[James Page]

This issue can be fixed by re-adding the required Start/Stop bits to the
LSB header; however the behaviour of update-rc.d when native systemd
unit files are in use looks odd to me.

Raising an init-system-helpers bug task for foundations team input on
this.

** Also affects: init-system-helpers (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1727063

Title:
  Pacemaker package upgrades stop but fail to start pacemaker resulting
  in HA outage

Status in OpenStack hacluster charm:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New
Status in pacemaker package in Ubuntu:
  Triaged
Status in init-system-helpers source package in Xenial:
  New
Status in pacemaker source package in Xenial:
  Triaged
Status in init-system-helpers source package in Zesty:
  New
Status in pacemaker source package in Zesty:
  Triaged
Status in init-system-helpers source package in Artful:
  New
Status in pacemaker source package in Artful:
  Triaged
Status in init-system-helpers source package in Bionic:
  New
Status in pacemaker source package in Bionic:
  Triaged

Bug description:
  [Impact]
  upgrades of the pacemaker package don't restart pacemaker after the package 
upgrade, resulting in down HA clusters.

  [Test Case]
  sudo apt install pacemaker
  sudo systemctl start pacemaker
  sudo dpkg-reconfigure pacemaker

  pacemaker daemons will not be restarted.

  [Regression Potential]
  TBC as not quite sure where the fix for this is.

  [Original Bug Report]
  We have found on our openstack charm-hacluster implementations that the 
pacemaker .deb packaging along with the upstream pacemaker configuration result 
in pacemaker stopping but not starting upon package upgrade (while attended or 
unattended).

  This was seen on three separate Xenial clouds.  Both Mitaka and Ocata.

  The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2.

  It appears that pacemaker.prerm stops the service using
  "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to 
start the service, but silently fails due to policy denial.  It appears the 
policy check fails because /etc/rcX.d/S*pacemaker does not exist because 
/etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB 
init headers.  (or rather, they are blank.)

  I have not checked whether this affects trusty environments.

  I'd suggest on systems that use systemd, the pacemaker.postinst script
  should check if the service is enabled and start it with systemctl
  commands rather than using the cross-platform compatible invoke-rc.d
  wrappers.  Or upstream pacemaker should get default start/stop
  entries.

  Our default runlevel on cloud init built images appears to be 5
  (graphical), so at least 5 should be present in /etc/init.d/pacemaker
  LSB init headers under Default-Start:.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+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