>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