Your message dated Fri, 10 Jun 2016 11:36:25 -0400
with message-id
<CAAfdZj_6TmeAcO7S7=ankc-raut9wuhenhdrtatfczjnhv8...@mail.gmail.com>
and subject line Re: Bug#826722: [systemd] insserv-generator does not generate
target file for additional system facilities
has caused the Debian Bug report #826722,
regarding [systemd] insserv-generator does not generate target file for
additional system facilities
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
826722: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826722
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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 ---
Index: systemd-215/src/insserv-generator/insserv-generator.c
===================================================================
--- systemd-215.orig/src/insserv-generator/insserv-generator.c
+++ systemd-215/src/insserv-generator/insserv-generator.c
@@ -179,6 +179,31 @@ static int parse_insserv_conf(const char
char *name, **j;
FILE *file = NULL;
+ _cleanup_free_ char *target = NULL;
+
+ target = strjoin(arg_dest, "/", facility, NULL);
+ file = fopen(target, "wxe");
+ if (!file) {
+ if (errno == EEXIST)
+ log_error("Failed to create target file %s", target);
+ else
+ log_error("Failed to create target file %s: %m", target);
+ return -errno;
+ }
+
+ fprintf(file,
+ "# Automatically generated by systemd-insserv-generator\n\n"
+ "[Unit]\n"
+ "Description=%s\n",
+ facility);
+ fflush(file);
+ if (ferror(file)) {
+ log_error("Failed to write unit file %s: %m", target);
+ return -errno;
+ }
+ fclose(file);
+
+
STRV_FOREACH (j, parsed+1) {
_cleanup_free_ char *unit = NULL;
_cleanup_free_ char *dep = NULL;
insserv-test.tar.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Hi Andre,
On 8 June 2016 at 07:18, Andre Naujoks <[email protected]> wrote:
> 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.
I am sorry that you invested time on this patch, as I'm afraid we won't take it.
For stretch, we are targeting the dropping of the insserv generator.
The generator was always meant to be a stop-gap measure until the
providers of the standard facilities gained native systemd units. We
are closing in on the target, with only a few packages left to fix
(the $named providers) before we can drop it.
The insserv generator has always been fairly limited, because the long
term plan was always to drop it. For example, it also doesn't support
/etc/insserv/overrides.
As for jessie, this is a behavior change and out of scope of the
transitioning purpose of the generator, and as such not something we'd
like to push for in a stable update.
Sorry.
--
Saludos,
Felipe Sateler
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
