Fork: 0
tundra / deconstructing_udev
Browse code
Flushed out whole document structure and wrote several new sections.
master
1 parent 2e050d9 commit 6f250ef23ece5b2afdb9f91053fa53595f83509f
@tundra tundra authored on 31 Oct 2013
Patch
Unified Split
Showing 1 changed file
View
96
■■■■■
 Deconstructing_Linux_udev_Rules.rst
 
Where Do ``udev`` Rules Live?
=============================
 
User created rules - well, created by ``root``, actually - are found in
``/dev/udev/rules.d``. If you look there, you'll see that the files
there begin with numbers like ``50`` or ``60``. ``udev`` reads rules
in *lexical order*. That means it reads the ``50...`` file before the
``60...`` file before the ``70...`` file and so on. This is important
because you have to be careful to insert your rule in early enough in
the lexical order so that it can override any subsequent defaults.
 
Unfortunately, because of the way ``udev`` works, rules read later
in the lexical order can also *override* earlier rules if we're not careful.
We'll see an example of this below, and how to fix it.
 
In our case, we'll create our rules in the file
``15-ExampleRules.rules`` which should pretty much guarantee that our
rules will be the first ones read.
 
 
How Does ``udev`` Read Rules
============================
 
When ``udev`` first starts, or any time it is informed that rules have
been changed, it first reads a set of system-wide default rules in
``/lib/udev/rules.d/``. Then it reads the rules in
``/etc/udev/rules.d``. If you name your own rule file the same as one
of system-wide rules, yours will take precedence. There is also a way
to install "temporary" rules, but the location for such rules is
distro-specific.
 
Ordinarily, the running ``udev`` daemon is automatically informed
that a rule file has changed and it will reread them all again
when this happens. You can also force a rule reload with::
 
udevadm control --reload-rules
 
You can also restart the ``udev`` daemon or reboot to get
the latest rules read in. It seems that the daemon restart
procedure is distro-specific so you'll have to figure out what
works on your system.
 
 
Our Example Rules
=================
 
We need two rules to achieve our goals above. Notice that the first
rule below is broken across multiple lines to make it more readable,
but it is all on one line in the actual rules file. It is possible to
break rules across lines but you have to ensure that you follow the
syntax that ``udev`` expects. To keep things simple, I put the
entire rule one one line::
 
KERNEL=="sd*", PROGRAM=="/sbin/scsi_id --whitelisted /dev/$name",
RESULT=="1ATA_VBOX_HARDDISK_VB5f712327-2bb4be0c", SYMLINK+="my_fine-disk01",
OWNER:="3009", GROUP:="421", MODE:="0600",
RUN=="/bin/raw /dev/raw/raw1 /dev/$name"
 
KERNEL=="raw1", SYMLINK+="rmy_fine-disk01", OWNER:="3009", GROUP:="421", MODE:="0600"
 
 
What Does All This Mean?
========================
 
Rules are made up of key-value pairs separated by an operator. These
key-value pairs are separated by commas. Let's take each rule apart,
one key-value pair at a time:
 
 
- ``KERNEL=="sd*"``
- ``PROGRAM=="/sbin/scsi_id --whitelisted /dev/$name"``
- ``RESULT=="1ATA_VBOX_HARDDISK_VB5f712327-2bb4be0c"``
- ``SYMLINK+="my_fine-disk01"``
- ``OWNER:="3009"``
- ``GROUP:="421"``
- ``MODE:="0600",``
- ``RUN=="/bin/raw /dev/raw/raw1 /dev/$name"``
 
Now, let's look at the second rule:
 
- ``KERNEL=="raw1"``
- ``SYMLINK+="rmy_fine-disk01"``
- ``OWNER:="3009"``
- ``GROUP:="421"``
- ``MODE:="0600"``
 
 
 
Other Thoughts
==============
 
Obviously, you'd have to have another pair of rules for each additional
disk you want to manage this way. Adding another disk would be a matter
of using ``scsi_id`` to get its ``wwid`` and for the ``RESULT`` field
of the first rule. You'd also have to change references to ``my_fine_disk01``
and ``raw1``.
 
For reasons that are not entirely clear (to me anyway), the ``raw``
command only knows how to create raw devices whose names begin with
``raw``, go figure.
 
 
Author
======
 
Document Revision Information
=============================
 
``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.105 2013/10/31 21:52:20 tundra Exp $``
``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.106 2013/10/31 22:44:17 tundra Exp $``
 
You can find the latest version of this document at:
 
http://www.tundraware.com/TechnicalNotes/Deconstructing-Linux-udev-Rules