"udevadm settle" and "init"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey,

the underlying problem described below, is in no way specific to
systemd, it applies to all modern systems and services, existing ones,
or ones not even developed.

The udev systemd service files for udev do no longer pull-in the
barrier 'udevadm settle'. The udev coldplug run is executed fully
asynchronously in the background along with many other services, and
no other service will be blocked by default, waiting for udev to
populate /dev.

That means: non-hotplug-aware services are likely to break. Services
which assume a static /dev, rely on scanning /dev and finding "all"
devices at a certain point in time, are required to explicitly pull-in
udev-settle.service to paper-over their inability to cope with a
dynamic system. It will block the broken service until udev's coldplug
run has finished and /dev is populated with all devices known at that
time.

It's 2011 and services should cope with hotplug, devices coming and
going at any time, and a constantly changing and re-configuring
environment. No service which wants survive the next years of Linux
evolution should depend on the udev-settle.service barrier though,
please fix your stuff, or the reality might go on without you. :)

There is libudev, which connects your service to meaningful event for
news devices, device changes, and allows you to enumerate all
currently existing devices. Subscribing to events before enumeration
is started will make sure not to miss anything, and to propagate later
changes into the service.

All that even works from python, java, mono, javascript, ... programs,
so there is no excuse anymore to continue to do any of the
much-too-simple things we all did in the past. Just stop making
assumptions like: "booting has finished" or "all devices are there" --
that never really was in the past, and it will never be true in the
future.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     [X.org]     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux