[Pkg-systemd-maintainers] Bug#720850: [RFC] Draft of ctte referal

[Bastian Blank]

Hi

I intend to refer this problem to the ctte.  I attached the draft.
Please comment if I made a factual error.

Bastian

Hi

Please decide if systemd is allowed to do subtle and incompatible
changes to the behaviour of init-scripts, especially the udev
init-script, by overriding them with it's own service definitions.

Introduction
============
systemd is a new and non-default implementation of /sbin/init for Linux
only in Debian.  It includes a new way to define services to be handled
by itself.  systemd includes backward compatibility support for
sysv-init-scripts and converts them into an service definition.  Some
incompatibilities exists, but they don't apply to this problem.
Existing service files always overrides init-scripts, so only one will
be used.

The udev package includes an init-script since a long time. This
init-script does multiple things: It starts udevd and makes sure all
devices are available after it finished.  This script is still included
in the current udev package and used if sysv-rc is active, which is
still the default in Debian. (The alternative file-rc also uses it.)
All the init-script that needs devices somehow depend on the udev
init-script.

systemd includes udev.service.  The was a real file, but is now a
symlink to systemd-udevd.service for compatibility reasons.  This
service globaly overwrites the udev init-script.  It only does one
thing: Start udevd.  It does not handle the waiting for devices part.
Because the udev service only does half the work of the old udev
init-script, it is not longer equivalent.

The difference between the udev init-script and the service breaks the
lvm2 init-script, which relys on the behaviour of the init-script.
Other packages may be also affected.

Timeline
========
A bug was reported against systemd (#718190).[1]  It was analyzed by
Michael Stapelberg and he found that the lvm2 init-script not always
finds all devices.

[1]: http://bugs.debian.org/718190

Michael reported a bug against lvm2 (#719738).[2]  It asks for the
activation of a so called generator, which generates systemd services on
run-time.  No indication was given about the real reason why this is
necessary.

[2]: http://bugs.debian.org/719738

After some messages back and forth to find out the real reason, Michael
declared that the udev service deliberately only does half of the
work of the old init-script.[3]  The reason was something like, because
upstream does it this way.  No additional reason or own view was given.

[3]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738#32

After some further questions without replies, I decided to call this a
bug in systemd,[4] because neither a reason for this difference was
given, nor a patch to support both variants.  I cloned two bugs, one for
the compatiblity stuff (#720850)[5] and another about the usage of
predictable filenames in /tmp, I found during inspection of the systemd
package (#720851)[6].  The original bug remained to track addition of
systemd support into lvm2 as improvement.

[4]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738#57
[5]: http://bugs.debian.org/720850
[6]: http://bugs.debian.org/720851

I outlined a plan to add systemd support in the same mail.  This variant
does not need the Red Hat supplied generator to work.  I did not
consider using the supplied generator a viable option, as it has a bunch
of problems, which may make it error-prone, and fails in the wrong
direction without providing a fallback.

The bug about the incompatibility issue of the udev service was closed
almost immediately by Michael.[7]

[7]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720850#76

The bug about the predictable filenames was also closed without a look
into the actual source.[8]  To make it easier for them, I actually
showed them their own code.[9]

[8]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720851#78
[9]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720851#83

After that I closed the original bug-report, as proper backward
compatibility in the systemd package itself fixes this problem in any
case.  The proposed systemd suport would only make it more clear in the
first step.  Only lvmetad support will be able to change this.

udev init-script vs. udev.service
=================================
The udev init-script does three things:
- Start udevd.
- Do a sweep of all known devices to trigger handling by udev.  This is
  called "coldplug".
- Wait for all devices to be available.
It has been this way since a long time.  The description tells:[10]
# Short-Description: Start udevd, populate /dev and load drivers.

[10]: udev_204-2_*.deb:/etc/init.d/udev

systemd-udevd.service (and the symlink udev.service), which replaces the
udev init-script if systemd is used, only does one thing:[11]
- Start udevd.

[11]: udev_204-2_*.deb:/lib/systemd/system/systemd-udevd.service

There is a systemd-udev-settle.service.  This one does all the work of
the udev init-script, aka it waits for all devices to be available.  It
includes the following comment:[12]
# This service can dynamically be pulled-in by legacy services which
# cannot reliably cope with dynamic device configurations, and wrongfully
# expect a populated /dev during bootup.

[12]: udev_204-2_*.deb:/lib/systemd/system/systemd-udev-settle.service

The lvm2 service would need to depend on systemd-udev-settle.service
anyway to work currently.  Also there are other init-scripts with the
udev dependency, which seems to rely on the old behaviour.

Conclusion
==========
systemd tries to convert the whole system setup event based.  I don't
have problems with that, because it can make the whole stuff easier to
handle, but with the introduction of more subtle pitfalls.  It only
works only on Linux and not the other kernels supported by Debian.

However the systemd maintainers in Debian try to force unrelated changes
on all existing stuff.  They deliberately decided that "udev" in an
init-script does not longer mean A+B, but only A.  Now they want to
change all the stuff that actually depends on it meaning A+B to adopt
and force the availability of B another way.

In Debian we usualy try to find a way that works for all parties.  I was
even prepared to actually invest time into the systemd matter and
improve the experience for our users.  But I made the decision to wait
until systemd was fixed and it would be actually an improvement and not
a workaround.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
		-- Kirk, "Elaan of Troyius", stardate 4372.5