Am 01.10.18 um 00:55 schrieb Trek: > On Sat, 29 Sep 2018 18:41:45 +0200 > Michael Biebl <bi...@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?
signature.asc
Description: OpenPGP digital signature
