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.
Update: Note! The issue was fixed in CentOS/RHEL 5.2 !
glibc 2.7 introduces a new flag to open() syscall, called O_CLOEXEC.
The official redhat 2.6.18 kernel (even of version 5.1) doesn't support it, and returns errors (in strace it looks like open() returns unknown error 530).
So.. just try not to use glibc 2.7 on RedHat, until they support it. If you want an adventure, this kernel seems to do the job..
How did I encounter this uncommon problem, you ask? I'm running Debian unstable VM inside a CentOS5 host (the VM's kernel is actually a CentOS5 kernel). Debian upgraded glibc to 2.7, and later the VM couldn't function (open /etc/passwd gave error 530). Not too smart of me, I guess. But dzickus kernel seems to solve it.
Do you remember DOS games or apps quitting with the reason 'not enough memory'? It rarely happens today, because physical ram is not the limit - physical ram + swap, or virtual memory size is the limit.
So what happens when we're out of virtual memory? Linux doesn't crash. Instead, it looks for the best process(es) to kill. "Best" means: killing the process will free up lots of memory, but will do the least damage possible (i.e. don't kill init, hardware-bound process, or a long-running software).