Package: init-system-helpers Version: 1.69 Severity: normal Tags: patch Hello init-system-helpers maintainers,
currently, systemd-sysv Conflicts with insserv and this was added (see #1072562 for details) because update-rc.d wrongly runs it even on systems which use systemd to boot. I propose the following patch to fix this behaviour and prevent insserv from being run on systems which use systemd as init: https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/33 --- a/script/update-rc.d +++ b/script/update-rc.d @@ -192,6 +192,10 @@ sub create_sequence { $insserv = "/sbin/insserv" if ( -x "$dpkg_root/sbin/insserv"); # If insserv is not configured it is not fully installed my $insserv_installed = -x "$dpkg_root$insserv" && -e "$dpkg_root/etc/insserv.conf"; + # Ignore the presence of insserv if this system is using systemd as init + if ($insserv_installed && readlink "$dpkg_root/usr/sbin/init" eq "../lib/systemd/systemd") { + $insserv_installed = 0; + } my @opts; push(@opts, '-f') if $force; # Add force flag if initscripts is not installed An alternative patch would be to use: my $insserv_installed = -x "$dpkg_root$insserv" && -e "$dpkg_root/etc/insserv.conf" && readlink "$dpkg_root/usr/sbin/init" ne "../lib/systemd/systemd"; And if the link target could potentially be different, maybe the check should be made less strict (just to be overly safe) by testing: readlink "$dpkg_root/usr/sbin/init" =~ /systemd/; The test uses /usr/sbin/init to check for systemd and not the usual /run/systemd/system as is used by debhelper snippets because we do not want to find out which init system the currently running system uses but we want to know which init the system we are operating on is going to use. The difference between the two comes into play when update-rc.d is run inside a chroot where systemd is not running but systemd-sysv is installed and provides /usr/sbin/init. Yet another way to check would be to test with dpkg-query whether systemd-sysv is installed or not but I think it would be safer to check for the actual files and not rely on systemd being installed via dpkg. There was no maintainer response on salsa and hence I'm submitting this bugreport to solicit feedback for this change. The only feedback which I have received so far was from Michael Biebl in IRC #debian-devel on March 11 2026. Michael disagreed to a change of update-rc.d but without giving technical reasons. Michael suggested that another package built by src:insserv could install the insserv binary into /usr/libexec to make it available outside of $PATH. I filed #1132024 against src:insserv with the suggested change and a patch but received pushback from its maintainer as well. My motivation for allowing the installation of the insserv binary package on a system which boots with systemd is to create chroots for GNU/Hurd which does not support systemd. Other reasons include that it would make the development for startpar, runit, openrc and insserv itself easier. The existing conflict with insserv causes autopkgest failures on ci.d.o where systemd cannot be uninstalled from the testbed. Since support for LSB initscripts got removed from systemd, I wonder which technical reason remains for systemd-sysv to conflict with insserv other than update-rc.d without the proposed patch. If you know about other technical challenges I would like to investigate them. If you do not disagree with the proposed change and are short on time I can offer to upload this change as a NMU of init-system-helpers. Thanks! cheers, josch
