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
+ and <filename>/lib/udev/</filename>. All empty lines or lines beginning with
'#' will be ignored.</para>
<refsect2><title>Configuration file</title>
<para>The udev rules are read from the files located in the
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>/var/run/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
<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>
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
<varlistentry>
<term><option>event_timeout=</option></term>
<listitem>
- <para>Number of seconds an event will wait for operations to finish, before it
+ <para>Number of seconds an event will wait for operations to finish before it
will terminate itself.</para>
</listitem>
</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>
<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