udevadm, and why you should stop what you're doing
There's a bit of a meme going around that it's safe to call udevadm (or
its symlinks like udevtrigger/udevsettle) from package maintainer
scripts without worrying about it.
I'm afraid to tell you that it isn't.
Here's a quick guide to what is safe to call:
I want to find out information about a device.
This is safe to call, and in recent releases
returns all information; combining both the udevdb and the
kernel uevent info.
It's even better to use libudev if you're writing code ;-)
I've built a module, and want to see if it's needed for anything on
*NOT* udevadm trigger. I just filed a Critical bug against dkms
Just modprobe it. If no devices are claimed, then the module
will not be loaded and modprobe will return an exit code. If
devices are claimed, it'll return 0.
You need to depend on module-init-tools, of course; because
you're probably going to call things like depmod first
I've installed udev rules and want udev to do something about it.
udevadm trigger --action=change
*and* Depend on udev (you can't udevadm when udev is
The action argument is of utmost importance. Without it, the
kernel will tell udev to treat all devices as *NEW*. This will
have lots of side-effects you are probably not expecting.
"change" is completely safe. It tells udev just to refresh
devices, and make sure everything's as it should be.
(This solves the network manager double-interface bug, the "my
disk is corrupt until after reboot" bug, etc.)
I've loaded a module, or called an ioctl(), or poked the kernel in
some other way, and I want udev to finish processing it.
*and* Depend on udev.
There is no need for a trigger call; udevd is running, it'll get
the uevents from the kernel anyway. Trigger would just resend
them (along with uevents for the entire rest of the system
-which will have dangerous side-effects).
settle waits for udevd to finish processing any uevents queued
by the kernel when it is called.
This allows you to ensure the device node is created, or any
programs udev runs like vol_id are no longer running.
There are conditions it does not wait for:
- if you load a module for a bus, it won't wait for all devices
on that bus to show up -- it will only wait for the bus
to appear under /sys/bus
there's no such things as "probe completion" for just about
any bus you can name, your software simply needs to deal with
the fact that devices may show up at any time
- if you load a module containing a device driver, the driver
will claim all devices but the "class device" may not appear
e.g. loading a network card module doesn't mean that eth0 will
it means that the pci device is claimed and the driver
initialised; it may be calling out for firmware, or performing
asynchronous initialisation of some kind
the class device will show up later, or may not show up at all
Scott James Remnant
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel