Bug #826214: Bug #826215: init-d-script and systemd: solution

[Christian Seiler]

Hi there,
(Cc'd a lot of people, so that hopefully everybody relevant
is included.)

Andreas Henriksson recently pointed me to the fact that there
are several problems with the current init-d-script in Debian
(which I use in my own packages to handle the non-systemd
cases), and he most prominently mentioned the problem that
with init-d-script systemctl redirection via direct calls to
the init script doesn't work properly (in contrast to normal
init scripts, where it does).

What bothered me is that many people (including Andreas) have
started suggesting not to use init-d-script because of its
problems but to rather use the previous template. I think
this is the wrong approach, because I'm perfectly happy in
maintaining something like:

http://sources.debian.net/src/open-isns/0.96-5/debian/open-isns-server.isnsd.init/
http://sources.debian.net/src/open-isns/0.96-5/debian/open-isns-discoveryd.isnsdd.init/

in my packages, but I would hate to have to maintain all of
the boilerplate code.

For this reason I promised Andreas that I'd take a closer look
at those and see what I can do.

I think I have a solution to both issues - and my solution
does not require any change to any individual init script,
and best of all it doesn't even require changes to any
sysvinit-related package (we get to have our cake and eat
it too):

The systemd package could install a diversion of
/lib/init/init-d-script and install its own wrapper. The
wrapper could check for systemd being run and properly handle
the redirect-to-systemctl case. On systems that have systemd
installed but are booted with something else the wrapper
would just source the original wrapper.

This has two distinct advantages:

 - diversions now work properly for init-d-scripts
   (fixes #826214)

 - scripts that use init-d-script _and_ have a native systemd
   service with the same name _and_ do _not_ implement custom
   verbs in the init script (do_unknown) don't need to depend
   on sysvinit-utils anymore. At the same time the entire
   init-d-script logic does _not_ need to be installed on
   such systems. (init-d-script packages without a native
   services still need the dependency though, as expected.)
   (fixes #826215)

I've developed a patch against current sid of the systemd
package and tested that on both systemd and sysvinit systems
extensively and made sure all of the code paths work.

The wrapper itself doesn't have much code, but I've added a
lot of comments to make sure that the corner cases (that are
all handled properly) are understood, so people modifying it
don't break it accidentally.

For the sysvinit people, to make it clear thst it doesn't
harmfully affect non-systemd systems: the basic structure of
the wrapper is the following:

#!/bin/sh
if [ -d /run/systemd/system ] ; then
  # do systemd-specific stuff
fi
. /lib/init/init-d-script.sysv
exit $?

I have tested the following (with real live packages):

 - systems booted with systemd, sysvinit-utils installed:
   redirection works as expected, custom verbs are still
   handled by init-d-script. The usage message is printed
   by the original init-d-script.

 - systems booted with systemd, sysvinit-utils not installed:
   redirection works as expected, the usage message is
   printed by the wrapper

 - systems booted with sysvinit, systemd not installed:
   everything still works

 - systems booted with sysvinit, systemd installed: the
   wrapper is a noop that just redirects to the original
   init-d-script

 - systems booted with sysvinit: installing a daemon,
   calling the init script, installing systemd (the package),
   calling the init script again, purging systemd, calling
   the init script yet again

I've done these tests multiple times with various different
packages and made sure I was hitting every code path of the
added code.

I've attached a git am'able patch against systemd's
debian/232-8 tag in git. Feedback welcome.

Regards,
Christian

PS: There is one corner case that is still open when it comes
to init-d-script and systemd, which is technically neither of
these bugs, but I feel I should mention it: if no native
systemd service is provided in addition to the init-d-script
init script, then systemd still doesn't properly detect
whether reload is possible for that service. I don't think
this is a huge issue, because that can easily be worked
around by providing a native systemd service in addition to
the init script. One could detect this properly by adding
support to detect this to systemd's sysv-generator (or add an
additional new generator), but I don't think that is worth
the effort.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-wrapper-for-init-d-script.patch
Type: text/x-patch
Size: 9379 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20161225/6a85e7ed/attachment.bin>