- Package:
- init-system-helpers
- Source:
- init-system-helpers
- Submitter:
- Johannes Schauer Marin Rodrigues
- Date:
- 2026-08-11 08:23:02 UTC
- Severity:
- normal
- Tags:
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
Josch,
Thanks very much for raising this issue and for the suggested solutions. Your
approach looks technically sound to me.
I would like to add my support for this change to be accepted. In addition to
your motivation in respect of GNU Hurd, I would like to point out another use
case that would benefit.
Currently autopkgtests for insserv and dependencies (openrc, startpar) fail when
run on ci.debian.net. This is because systemd-sysv is already installed in the ci
testbed cannot be removed:
autopkgtest [18:10:19]: test upstream: preparing testbed
Reading package lists...
Building dependency tree...
Reading state information...
Solving dependencies...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
satisfy:command-line : Depends: insserv but it is not going to be installed
E: Unable to satisfy dependencies. Reached two conflicting assignments:
1. insserv:amd64 is selected for install because:
1. satisfy:command-line:amd64=1 is selected for install
2. satisfy:command-line:amd64 Depends insserv
2. insserv:amd64 is available in version 1.27.0-1
but none of the choices are installable:
- insserv:amd64=1.27.0-1 is not selected for install because:
1. systemd-sysv:amd64 is selected for install
2. systemd-sysv:amd64 Conflicts insserv
upstream FAIL badpkg
blame: insserv
Insserv autopkgtest passes when run locally on a testbed without systemd-sysv
installed.
Fixing update-rc.d behaviour on systemd systems even if insserv is installed
would allow systemd-sysv Conflicts: insserv to be removed, and the insserv and
related autopkgtests would then pass on ci.d.n.
I appreciate that systemd maintainers have little interest in spending time and
effort in this area. Accordingly and like Josch, I am happy to offer an NMU of
src:init-system-helpers with this fix.
With best wishes
Mark
Hello systemd maintainers & Luca,
Quoting Mark Hindley (2026-07-13 09:22:49)
since there has been no maintainer reply to this bug for two weeks and since
there has not been any reaction to my MR on salsa [1] for three months, I'd
like to announce to you that I uploaded a NMU of init-system-helpers with
maximum delay of 15 days. You can find the debdiff at the end of this email.
If you decide to cancel the NMU, please consider also explaining what you think
that the proposed changes are breaking or why they are wrong. I am uploading
the NMU in good faith and am CC-ing the package maintainer as well as the last
uploader explicitly so that they can intervene if necessary.
Thanks!
cheers, josch
[1] https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/33
diff -Nru init-system-helpers-1.69/debian/changelog init-system-helpers-1.69+nmu1/debian/changelog
--- init-system-helpers-1.69/debian/changelog 2025-08-15 20:46:44.000000000 +0200
+++ init-system-helpers-1.69+nmu1/debian/changelog 2026-07-27 09:02:23.000000000 +0200
@@ -1,3 +1,11 @@
+init-system-helpers (1.69+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Ignore the presence of insserv if system is booting using systemd as init
+ (Closes: #1141215)
+
+ -- Johannes Schauer Marin Rodrigues <josch@debian.org> Mon, 27 Jul 2026 09:02:23 +0200
+
init-system-helpers (1.69) unstable; urgency=medium
* Add postinst to hotfix an upgrade bug on certain newly live-installed
diff -Nru init-system-helpers-1.69/script/update-rc.d init-system-helpers-1.69+nmu1/script/update-rc.d
--- init-system-helpers-1.69/script/update-rc.d 2023-11-24 13:34:19.000000000 +0100
+++ init-system-helpers-1.69+nmu1/script/update-rc.d 2026-07-27 09:01:29.000000000 +0200
@@ -192,6 +192,10 @@
$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
We believe that the bug you reported is fixed in the latest version of
init-system-helpers, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1141215@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Johannes Schauer Marin Rodrigues <josch@debian.org> (supplier of updated init-system-helpers package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 27 Jul 2026 09:02:23 +0200
Source: init-system-helpers
Architecture: source
Version: 1.69+nmu1
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Johannes Schauer Marin Rodrigues <josch@debian.org>
Closes: 1141215
Changes:
init-system-helpers (1.69+nmu1) unstable; urgency=medium
.
* Non-maintainer upload.
* Ignore the presence of insserv if system is booting using systemd as init
(Closes: #1141215)
Checksums-Sha1:
037b31cfee9a5273138e6b141853f25a261506b0 2327 init-system-helpers_1.69+nmu1.dsc
be343b346a1ae8093c3b1c5c1a682d01d63dadec 45776 init-system-helpers_1.69+nmu1.tar.xz
68b33b14a1834a942d749d2036a0fc131f4ee186 7189 init-system-helpers_1.69+nmu1_source.buildinfo
Checksums-Sha256:
df61b1473575eba598f98a7828a37bd2e5dfa96cd8f118233a16c9a8fd130099 2327 init-system-helpers_1.69+nmu1.dsc
4aa70e315f51398860883de524232dbbd7edd8373a3901d32ae62b826fae2ad3 45776 init-system-helpers_1.69+nmu1.tar.xz
6363c7a04c3f6172121196129c6532f7822fc56d1200e56f33bfb9b5e9b19331 7189 init-system-helpers_1.69+nmu1_source.buildinfo
Files:
7d438c25690db5eeb796777fc5869547 2327 admin optional init-system-helpers_1.69+nmu1.dsc
3fc20d3d0cee452d5ada34c9429bb523 45776 admin optional init-system-helpers_1.69+nmu1.tar.xz
84bd797f70c069e4c00b2b619b603b92 7189 admin optional init-system-helpers_1.69+nmu1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
wsG7BAEBCgBvBYJqZwKTCRDyy6XHj72D4UcUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmdHhd06qcprEmvQ1lh9dva/ctYi2dkWLei2jHNZWnpM
9BYhBJRYVOii/NSxeMFaufLLpcePvYPhAADgjBAAobGnNIoccUKFzUNUaroVnpY3
LAonDX+jCbtvkkyI+AopSy+wW4CBBfhGN7sAVpVKTxVK1qKk2e+bXoxl1U94Cq8R
fjf4qeToOZ23LjIErSfqnP3utrS501GW4aR8ENmuaKUt8t56yH3gHqmLtn8WXJ2L
jYhtGzdWP07j6VKKDAa9jwevz6kv2NSmFkOT5ibUSd3GmNGo98OiWGbDhBMBkrE/
vFTa6fKkt3jHRTCKCstDF6FsCXSAJAEe5YWgrc80v6Xym3pLvvHP4gQxMSBbs0fb
W+r3Gucw1HtD8fMj/SwnTD4/Tv5qfh+FusuQgtTMA0c2CisliN6Yim/pfJITizkk
fIL7fXGRLlxcpkLY0aAW+vmR6M+4HCtLwWLwGPMjH38W1yySKQBLq/YXCJIVQ0H5
fCKWUH1VSX4AgU/gwBZdf8NQaPJZ/cpY4ybKLDAmMufcjhtElayP3gmC0wemL2qa
bteepSf5d2A16HNlMfVf9AKvOzuxLlpaq9XjYOuO895FrDAN9DID++xcJoMyQ1NH
OV0jyi45qO/HzIyuKAwIKDN90SjwwxLdYq+2xnVO6O6aZ5icLRkZ9EIHrSDXOpqd
kMlToRfnWfiYHjO8Xn4tgwZ1tmgIIyIXUQaMTcCES8p24Vdkx9AQO2wnH54bVfxo
xdmjDjYZaqS8zH+c0d0=
=cNVH
-----END PGP SIGNATURE-----