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