[systemd-devel] "udevadm settle" and "init"

Kay Sievers kay.sievers at vrfy.org
Thu Mar 31 11:35:39 PDT 2011


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


More information about the systemd-devel mailing list