names provide a way to reliably identify devices based on their properties or
current configuration.</para>
- <para>The udev daemon <citerefentry><refentrytitle>udevd</refentrytitle>
- <manvolnum>8</manvolnum></citerefentry> receives device uevents directly from
+ <para>The udev daemon, <citerefentry><refentrytitle>udevd</refentrytitle>
+ <manvolnum>8</manvolnum></citerefentry>, receives device uevents directly from
the kernel whenever a device is added or removed from the system, or it changes its
state. When udev receives a device event, it matches its configured set of rules
- against various device attributes to identify the device. Rules that match, may
- provide additional device information to be stored in the udev database, or information
+ against various device attributes to identify the device. Rules that match may
+ provide additional device information to be stored in the udev database or
to be used to create meaningful symlink names.</para>
- <para>All device information udev processes, is stored in the udev database and
+ <para>All device information udev processes is stored in the udev database and
sent out to possible event subscribers. Access to all stored data and the event
- sources are provided by the library libudev.</para>
+ sources is provided by the library libudev.</para>
</refsect1>
<refsect1><title>Configuration</title>
<para>udev configuration files are placed in <filename>/etc/udev/</filename>
- and <filename>/lib/udev/</filename>. All empty lines, or lines beginning with
- '#' will be ignored.</para>
+ and <filename>/lib/udev/</filename>. All empty lines or lines beginning with
+ '#' are ignored.</para>
<refsect2><title>Configuration file</title>
<para>udev expects its main configuration file at <filename>/etc/udev/udev.conf</filename>.
default rules directory <filename>/lib/udev/rules.d/</filename>,
the custom rules directory <filename>/etc/udev/rules.d/</filename>
and the temporary rules directory <filename>/run/udev/rules.d/</filename>.
- All rule files are sorted and processed in lexical order, regardless
- in which of these directories they live. Files in
- <filename>/etc/udev/rules.d/</filename> have precedence over files with
- the same name in <filename>/lib/udev/rules.d/</filename>. This can be
+ All rule files are collectively sorted and processed in lexical order,
+ regardless of the directories in which they live. However, files in
+ <filename>/etc/udev/rules.d/</filename> take precedence over files with
+ the same name in <filename>/lib/udev/rules.d/</filename>; this can be
used to ignore a default rules file if needed.</para>
- <para>Rule files must end in <filename>.rules</filename>, other extensions
- are ignored.</para>
+ <para>Rule files must have the extension <filename>.rules</filename>; other
+ extensions are ignored.</para>
- <para>Every line in the rules file contains at least one key value pair.
- There are two kind of keys, match and assignment keys.
+ <para>Every line in the rules file contains at least one key-value pair.
+ There are two kind of keys: match and assignment.
If all match keys are matching against its value, the rule gets applied and the
- assign keys get the specified value assigned.</para>
+ assignment keys get the specified value assigned.</para>
<para>A matching rule may rename a network interface, add symlinks
pointing to the device node, or run a specified program as part of
the event handling.</para>
- <para>A rule consists of a list of one or more key value pairs separated by
- a comma. Each key has a distinct operation, depending on the used operator. Valid
+ <para>A rule consists of a comma-separated list of one or more key-value pairs.
+ Each key has a distinct operation, depending on the used operator. Valid
operators are:</para>
<variablelist>
<varlistentry>
<varlistentry>
<term><option>=</option></term>
<listitem>
- <para>Assign a value to a key. Keys that represent a list, are reset
+ <para>Assign a value to a key. Keys that represent a list are reset
and only this single value is assigned.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>:=</option></term>
<listitem>
- <para>Assign a value to a key finally; disallow any later changes,
- which may be used to prevent changes by any later rules.</para>
+ <para>Assign a value to a key finally; disallow any later changes.</para>
</listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term><option>DRIVER</option></term>
<listitem>
- <para>Match the driver name of the event device. Only set for devices
+ <para>Match the driver name of the event device. Only set this key for devices
which are bound to a driver at the time the event is generated.</para>
</listitem>
</varlistentry>
<term><option>ATTR{<replaceable>filename</replaceable>}</option></term>
<listitem>
<para>Match sysfs attribute values of the event device. Trailing
- whitespace in the attribute values is ignored, if the specified match
- value does not contain trailing whitespace itself.
+ whitespace in the attribute values is ignored unless the specified match
+ value itself contains trailing whitespace.
</para>
</listitem>
</varlistentry>
<listitem>
<para>Search the devpath upwards for a device with matching sysfs attribute values.
If multiple <option>ATTRS</option> matches are specified, all of them
- must match on the same device. Trailing whitespace in the attribute values is ignored,
- if the specified match value does not contain trailing whitespace itself.</para>
+ must match on the same device. Trailing whitespace in the attribute values is ignored
+ unless the specified match value itself contains trailing whitespace.</para>
</listitem>
</varlistentry>
and removes the node before udev even receives any event. Changing
the node name from the kernel's default creates inconsistencies
and is not supported. If the kernel and NAME specify different names,
- an error will be logged. Udev is only expected to handle device node
+ an error is logged. Udev is only expected to handle device node
permissions and to create additional symlinks, not to change
kernel-provided device node names. Instead of renaming a device node,
SYMLINK should be used. Symlink names must never conflict with
- device node names, it will result in unpredictable behavior.</para>
+ device node names, it results in unpredictable behavior.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>SYMLINK</option></term>
<listitem>
- <para>The name of a symlink targeting the node. Every matching rule will add
+ <para>The name of a symlink targeting the node. Every matching rule adds
this value to the list of symlinks to be created. Multiple symlinks may be
specified by separating the names by the space character. In case multiple
- devices claim the same name, the link will always point to the device with
- the highest link_priority. If the current device goes away, the links will
- be re-evaluated and the device with the next highest link_priority will own
+ devices claim the same name, the link always points to the device with
+ the highest link_priority. If the current device goes away, the links are
+ re-evaluated and the device with the next highest link_priority becomes the owner of
the link. If no link_priority is specified, the order of the devices, and
- which one of them will own the link, is undefined. Claiming the same name for
+ which one of them owns the link, is undefined. Claiming the same name for
a symlink, which is or might be used for a device node, may result in
unexpected behavior and is not supported.
</para>
device. This can only be used for very short running tasks. Running an
event process for a long period of time may block all further events for
this or a dependent device. Long running tasks need to be immediately
- detached from the event process itself. If the option
- <option>RUN{<replaceable>fail_event_on_error</replaceable>}</option> is
- specified, and the executed program returns non-zero, the event will be
- marked as failed for a possible later handling.</para>
+ detached from the event process itself.</para>
<para>If no absolute path is given, the program is expected to live in
<filename>/lib/udev</filename>, otherwise the absolute path must be
specified. Program name and arguments are separated by spaces. Single quotes
<term><option>cmdline</option></term>
<listitem>
<para>Import a single property from the kernel commandline. For simple flags
- the value of the property will be set to '1'.</para>
+ the value of the property is set to '1'.</para>
</listitem>
</varlistentry>
<varlistentry>
</listitem>
</varlistentry>
</variablelist>
- <para>If no option is given, udev will choose between <option>program</option>
+ <para>If no option is given, udev chooses between <option>program</option>
and <option>file</option> based on the executable bit of the file
permissions.</para>
</listitem>
<varlistentry>
<term><option>event_timeout=</option></term>
<listitem>
- <para>Number of seconds an event will wait for operations to finish, before it
- will terminate itself.</para>
+ <para>Number of seconds an event waits for operations to finish before
+ giving up and terminating itself.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>static_node=</option></term>
<listitem>
<para>Apply the permissions specified in this rule to a static device node with
- the specified name. Static device nodes might be provided by kernel modules,
+ the specified name. Static device nodes might be provided by kernel modules
or copied from <filename>/lib/udev/devices</filename>. These nodes might not have
- a corresponding kernel device at the time udevd is started, and allow to trigger
- automatic kernel module on-demand loading.</para>
+ a corresponding kernel device at the time udevd is started; they can trigger
+ automatic kernel module loading.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>watch</option></term>
<listitem>
- <para>Watch the device node with inotify, when closed after being opened for
- writing, a change uevent will be synthesised.</para>
+ <para>Watch the device node with inotify; when closed after being opened for
+ writing, a change uevent is synthesised.</para>
</listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><option>$attr{<replaceable>file</replaceable>}</option>, <option>%s{<replaceable>file</replaceable>}</option></term>
<listitem>
- <para>The value of a sysfs attribute found at the device, where
+ <para>The value of a sysfs attribute found at the device where
all keys of the rule have matched. If the matching device does not have
such an attribute, and a previous KERNELS, SUBSYSTEMS, DRIVERS, or
ATTRS test selected a parent device, use the attribute from that
~ianmdlvl / elogind.git / blobdiff