Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20181004/0302d3b0/attachment-0002.sig>