Am 03.10.18 um 13:20 schrieb Trek: > > thanks to Bill Brelsford, the last test confirmed we are in the worst > situation: udev is running, the control file is created, but udev is > not ready to listen new events > > so we must to rethink about the 791944 bug: it was caused because udev > no longer removes the control file on stop > > we have at least three options to workaround it: > > 1) revert the 791944 patch, create a new init.d/udev-clear script to > remove the control file and run it just after sendsigs (this will > restore the old well tested behavior)
The removal of the control file should be bound to the live time of the udev service, so splitting it off into a separate init script is not a good idea. > 2) revert the 791944 patch, remove the control file on stop in > init.d/udev, stop it after sendsigs and remove udev from the Should-Stop > header in any script, probably cryptdisks, mdadm and lvm2 (this could > break any script that depends on udev and not distributed by debian) If you revert 791944, i.e. don't add the pid file to /run/sendsigs.omit.d, the systemd-udevd process will be killed by the sendsigs init script. Which means there is a time window where /run/udev/control exists but no functional udev service. In other words, not a proper solution either. > 3) do not revert, but start with udevd --background and create the > pidfile using pidof udevd (this could break if there are more than one > process of udevd) As you already mentioned, an approach using pidof is not going to work. For one thing, containers are a thing nowadays (and some containers run udev), and second, udevd will spawn off worker processes. Using pidof you don't know which process you will actually get. > what do you think about? None of the above proposals does really solve the problem, unfortunately. Afaics this problem is unfortunately not really fixable with the limited facilities sysvinit/sysv-rc provides. I'm of course happy if someone proves me wrong. Regarding the changes that were made for #791944, I'm ok with reverting them, if you want me to. Which means we will simply break the boot for another set of (sysvinit) users. A proper solution might (emphasis on might, as I haven't checked this) be to teach start-stop-daemon about daemons using the sd-notify interface. This is a more elaborate fix, for sure, but everything else feels like an incomplete hack. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
