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