On Fri, Aug 17, 2018 at 10:24 AM Michael Biebl <bi...@debian.org> wrote:
> Am 17.08.2018 um 15:13 schrieb Felipe Sateler: > > > Hmm. Commit 6f95680ffc9b1605841eb7d3d8eb92c790e6c73a looks like the > > culprit of the regression. But I'd like to understand why this happens. > > Shouldn't update-rc.d have enabled the service? > > The lldpad or corosync package ship a native systemd unit. > Looking at the generated postinst: > > > # Automatically added by dh_installinit/11.2.1 > > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = > "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then > > if [ -x "/etc/init.d/corosync" ]; then > > update-rc.d corosync defaults >/dev/null > > if [ -n "$2" ]; then > > _dh_action=restart > > else > > _dh_action=start > > fi > > invoke-rc.d corosync $_dh_action || exit 1 > > fi > > fi > > # End automatically added section > > # Automatically added by dh_installsystemd/11.2.1 > > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = > "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then > > # This will only remove masks created by d-s-h on package removal. > > deb-systemd-helper unmask 'corosync.service' >/dev/null || true > > > > # was-enabled defaults to true, so new installations run enable. > > if deb-systemd-helper --quiet was-enabled 'corosync.service'; then > > # Enables the unit on first installation, creates new > > # symlinks on upgrades if the unit file has changed. > > deb-systemd-helper enable 'corosync.service' >/dev/null || > true > > else > > # Update the statefile to add new symlinks (if any), which > need to be > > # cleaned up on purge. Also remove old symlinks. > > deb-systemd-helper update-state 'corosync.service' > >/dev/null || true > > fi > > fi > > # End automatically added section > > The problem is, that dh_installsystemd enables the service *after* a > start attempt has been made and > systemctl is-enabled checks for the state of the native service unit. > > With dh_systemd_enable/start, the enable part was before the start. > It's a bit like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887904 > > The old code worked, as it checked the status of the SysV init script, > not the enabled state of the native service file. > Right, the problem is that update-rc.d does not enable the systemd links, so we cannot drop this unless --skip-systemd-native was passed. I'll revert the change to unbreak things soon. For the longer term, maybe we can switch the check to /lib/systemd/systemd-sysv-install is-enabled $service ? This way we avoid some code duplication. -- Saludos, Felipe Sateler
