Bug#826722: [systemd] insserv-generator does not generate target file for additional system facilities
Andre Naujoks
nautsch at gmail.com
Wed Jun 8 12:18:33 BST 2016
Package: systemd
Version: 215-17+deb8u4
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
When creating a new system facility via /etc/insserv.conf.d/<file>, the
insserv generator generates drop-in files with ordering info for the
sysv-generator-created service files (which correspond to the
init-scripts with a "Required-Start: $<facility>" line in their
LSB-headers). The problem is, that the ordering is in relation to a
non-existent target and the ordering info is just ignored.
The attached patch creates this target via the insserv-generator.
The same bug is present in sids version, but the attached patch alone
does not seem to solve the problem completely for sid. For jessie
everything is well after this. I suspect some changes in the
sysv-generator, which might cause this.
One more thing. I don't know if this is actually the right approach to
make this work i.e. creating an almost empty <facility>.target file. If
there is a better/correct way of doing this, then I am very open to that.
I created a test setup to demonstrate the issue in the attached tarball.
It contains:
# the definition of the system factility: $testsysfac
etc/insserv.conf.d/testsysfac
# the first member of the system facility (basically a "sleep 2")
etc/init.d/testsysmem1
# the second member of the system facility (basically a "sleep 2")
etc/init.d/testsysmem2
# a service depending on the system facility (also a "sleep 2")
etc/init.d/testsysdep
to enable all of this:
update-rc.d testsysmem1 defaults; update-rc.d testsysmem2 defaults;
update-rc.d testsysdep defaults;
After this the links in /etc/rc*.d should have the right order i.e.
testsysdep after the testsysmems, which are basically irrelevant for
systemd.
However, when I boot with systemd the following happens (journalctl -b,
edited to only include relevant lines):
> Jun 08 12:34:40 jessie-vm systemd[1]: Cannot add dependency job for unit testsysfac.target, ignoring: Unit testsysfac.target failed to load: No such file or directory.
> Jun 08 12:34:40 jessie-vm systemd[1]: Cannot add dependency job for unit testsysfac.target, ignoring: Unit testsysfac.target failed to load: No such file or directory.
> ...
> Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac mem 2...
> Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac mem 1...
> ...
> Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac dependency...
> ...
> Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac mem 1.
> Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac mem 2.
> Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac dependency.
The plain ordering here is accidentally correct, but "test system fac
dependency" should not even have been started without first reaching the
testsysfac.target. Note that the 2 second pauses are also missing
between the starting of the services. Depending on the load order of
files, I have also seen a completely random order on another boot.
After the patch is applied:
> Jun 08 12:42:33 jessie-vm systemd[1]: Starting LSB: test system fac mem 2...
> ...
> Jun 08 12:42:33 jessie-vm systemd[1]: Starting LSB: test system fac mem 1...
> ...
> Jun 08 12:42:35 jessie-vm systemd[1]: Started LSB: test system fac mem 2.
> Jun 08 12:42:35 jessie-vm systemd[1]: Started LSB: test system fac mem 1.
> Jun 08 12:42:35 jessie-vm systemd[1]: Starting testsysfac.target.
> Jun 08 12:42:35 jessie-vm systemd[1]: Reached target testsysfac.target.
> Jun 08 12:42:35 jessie-vm systemd[1]: Starting LSB: test system fac dependency...
> Jun 08 12:42:37 jessie-vm systemd[1]: Started LSB: test system fac dependency.
Which honours the order of the services and actually uses the target.
The 2 second pauses are there and everything looks good.
Regards
Andre
--- System information. ---
Architecture: amd64
Kernel: Linux 4.6.0-trunk-amd64
Debian Release: stretch/sid
500 unstable ftp.de.debian.org 1 experimental
ftp.de.debian.org
--- Package information. ---
Depends (Version) | Installed
====================================-+-==================
libacl1 (>= 2.2.51-8) | 2.2.52-3
libapparmor1 (>= 2.9.0-3+exp2) | 2.10-4
libaudit1 (>= 1:2.2.1) | 1:2.5.2-1
libblkid1 (>= 2.19.1) | 2.28-5
libcap2 (>= 1:2.10) | 1:2.25-1
libcryptsetup4 (>= 2:1.4.3) | 2:1.7.0-2
libgpg-error0 (>= 1.14) | 1.22-2
libkmod2 (>= 5~) | 22-1.1
libmount1 (>= 2.26.2) | 2.28-5
libpam0g (>= 0.99.7.1) | 1.1.8-3.3
libseccomp2 (>= 2.1.0) | 2.3.1-2
libselinux1 (>= 2.1.9) | 2.5-3
libsystemd0 (= 230-2) | 230-2
util-linux (>= 2.27.1) | 2.28-5
mount (>= 2.26) | 2.28-5
adduser | 3.114
libcap2-bin | 1:2.25-1
Package Status (Version) | Installed
=============================-+-===========
udev | 230-2
Recommends (Version) | Installed
=============================-+-===========
libpam-systemd | 230-2
dbus | 1.10.8-1
Suggests (Version) | Installed
================================-+-===========
systemd-ui | systemd-container |
--- Output from package bug script ---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: insserv-generator-fix.patch
Type: text/x-patch
Size: 1360 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20160608/e8d2d122/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: insserv-test.tar.gz
Type: application/gzip
Size: 577 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20160608/e8d2d122/attachment-0001.bin>
More information about the Pkg-systemd-maintainers
mailing list