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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
