Ever wondered why a certain rule doesn't get run? Ever got confused (or disgusted) by udev rules format?
Well, despite all the udev clutter, there are many useful tools in the udev package, which help to understand udev's behavior and decision making. I'm still far from knowing all the tricks, but here are some things that I've learned recently:
Note: the udev tools got changed several times during the last 5 years. I'll cover here the latest version (149), and the older, RHEL/CENTOS5 version.
1. udevadm info: get all info available to udev about a certain device (or all devices):
# udevadm info -e (RHEL5: udevinfo -e)
Try it.. amazing, eh? You can use each detail to write udev rules to match these devices.
2. debug logging: see everything that udev does
a. On demand debugging: udev sends messages to syslog. Easiest way to see what udev does, is by increasing the log level. as easy as a pie:
# udevadm control --log_priority=debug (RHEL5: udevcontrol log_priority=debug)
b. boot in debug mode: most of udev actions are running at boot time, so we need a way to tell udev to start in debug mode. This way /var/log/messages would contain all udev actions messages starting with the very first one. Yes, syslog is down when udev starts.. Any idea how it works? 🙂
How to do it?
# edit /etc/udev/udev.conf: set udev_log="debug"
(RHEL5 has a nice trick: add udevdebug to the kernel boot parameters)
3. udevadm trigger - causes something like a device rescan:
All 'add' events are re-sent from the kernel, thus triggering all udev rules.
# udevadm trigger (RHEL5: udevtrigger)
4. udevadm settle - blocks until udev has finished working on its queue
Due to the asynchronous nature of modern kernels, commands may return before the expected action has ended. E.g.: a command for loading a kernel module might finish running before the network interface was really created. Therefore, if the next command expects a network interface, it should really wait until the interface got created. Ok, to the business:
# udevadm settle (RHEL5: udevsettle)
5. udevadm test, udevadm monitor
Sounds very useful, although I found above methods good for most scenarios, so I didn't dig test/monitor much.
I hope this article will be helpful. Do you have a cool udev tip or trick? Be nice and post it as a comment!
Thanks for the article. Minor correction: that should be log_priority, not log-priority.
Dan: fixed, thanks.
better double check that.. on my system (gentoo) it's --log-priority not --log_priority
Hello,
first, thanks a lot for this little but good tutorial.
I'm using "edit /etc/udev/udev.conf: set udev_log=â€info†for finding my mistake.
(about the possible use of "udevadm test" 🙂
Hi there,
Nice page !!
Only one thing: I used "udevadm info -e" which showed me for /dev/input/event4:
E: DMI_VENDOR=Sony Corporation
But when I tried to use
ENV{DMI_VENDOR}=="Sony Corporation"
to match the device in question, this did NOT work, which led me to use udevadm test ( also a very usefull command that you should add above 🙂
The command:
udevadm test /sys/class/input/event4
will do (at least) 2 things:
a) parse ALL your udev rules for SYNTAX ERRORS and show them to you!!
b) will show you the (reality) about /sys/class/input/event4
... "reality" because in this list (not sure why though) the DMI_VENDOR was NOT listed ! --> so I removed it from my udev rule and voila it worked.
Tormen.