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

Michael Biebl biebl at debian.org
Mon Oct 1 00:11:30 BST 2018


Am 01.10.18 um 00:55 schrieb Trek:
> On Sat, 29 Sep 2018 18:41:45 +0200
> Michael Biebl <biebl at debian.org> wrote:
> 
>>> +        # wait for udev to be ready (see #908796)
>>> +        timeout=15
>>> +        until udevadm control -S || [ $timeout -le 0 ]; do
>>> +            timeout=$((timeout-1))
>>> +            sleep 1
>>> +        done
>>> +        udevadm control -S && log_success_msg || log_failure_msg
>>
>> This repeatedly tries to start the execution queue.
>> Besides having this side-effect, why is this a proper test to check if
>> udev is ready?
> 
> this probably shows my ignorance about udev (and lack of documentation),
> but it seems to me there isn't a proper way to test if udev is ready

The only supported way in udev to signal readiness is the sd-notify API.
My gut feeling is, that having an sd-notify wrapper for non-systemd
systems (e.g. directly built into start-stop-daemon via say an
--wait-for-sd-notify switch) would be the cleanest and most robust way.
This might even benefit other daemons besides udevd.

Similar to what apulse is for PulseAudio clients without a PulseAudio
daemon.
-- 
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/20181001/80590b5d/attachment.sig>


More information about the Pkg-systemd-maintainers mailing list