-<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
SPDX-License-Identifier: LGPL-2.1+
-
- This file is part of systemd.
-
- Copyright 2012 Kay Sievers
- Copyright 2014 Jason St. John
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-
- systemd is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public License
- along with systemd; If not, see <http://www.gnu.org/licenses/>.
+ Copyright © 2014 Jason St. John
-->
<refentry id="udev">
<refentryinfo>
<title>udev</title>
<productname>systemd</productname>
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>Greg</firstname>
- <surname>Kroah-Hartmann</surname>
- <email>greg@kroah.com</email>
- </author>
- <author>
- <contrib>Developer</contrib>
- <firstname>Kay</firstname>
- <surname>Sievers</surname>
- <email>kay@vrfy.org</email>
- </author>
- </authorgroup>
</refentryinfo>
<refmeta>
</refsect1>
<refsect1><title>Rules Files</title>
- <para>The udev rules are read from the files located in the
- system rules directory <filename>/usr/lib/udev/rules.d</filename>,
- the volatile runtime directory <filename>/run/udev/rules.d</filename>
- and the local administration directory <filename>/etc/udev/rules.d</filename>.
- All rules files are collectively sorted and processed in lexical order,
- regardless of the directories in which they live. However, files with
- identical filenames replace each other. Files in <filename>/etc</filename>
- have the highest priority, files in <filename>/run</filename> take precedence
- over files with the same name in <filename>/usr/lib</filename>. This can be
- used to override a system-supplied rules file with a local file if needed;
- a symlink in <filename>/etc</filename> with the same name as a rules file in
- <filename>/usr/lib</filename>, pointing to <filename>/dev/null</filename>,
- disables the rules file entirely. Rule files must have the extension
- <filename>.rules</filename>; other extensions are ignored.</para>
+ <para>The udev rules are read from the files located in the system rules directories
+ <filename>/usr/lib/udev/rules.d</filename> and <filename>/usr/local/lib/udev/rules.d</filename>, the
+ volatile runtime directory <filename>/run/udev/rules.d</filename> and the local administration
+ directory <filename>/etc/udev/rules.d</filename>. All rules files are collectively sorted and
+ processed in lexical order, regardless of the directories in which they live. However, files with
+ identical filenames replace each other. Files in <filename>/etc</filename> have the highest priority,
+ files in <filename>/run</filename> take precedence over files with the same name under
+ <filename>/usr</filename>. This can be used to override a system-supplied rules file with a local
+ file if needed; a symlink in <filename>/etc</filename> with the same name as a rules file in
+ <filename>/usr/lib</filename>, pointing to <filename>/dev/null</filename>, disables the rules file
+ entirely. 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.
Except for empty lines or lines beginning with <literal>#</literal>, which are ignored.
value itself contains trailing whitespace.
</para>
</listitem>
+ </varlistentry>
+ <varlistentry>
<term><varname>SYSCTL{<replaceable>kernel parameter</replaceable>}</varname></term>
<listitem>
<para>Match a kernel parameter value.
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>CONST{<replaceable>key</replaceable>}</varname></term>
+ <listitem>
+ <para>Match against a system-wide constant. Supported keys are:</para>
+ <variablelist>
+ <varlistentry>
+ <term><literal>arch</literal></term>
+ <listitem>
+ <para>System's architecture. See <option>ConditionArchitecture=</option> in
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for possible values.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>virt</literal></term>
+ <listitem>
+ <para>System's virtualization environment. See
+ <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ for possible values.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>Unknown keys will never match.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>TAG</varname></term>
<listitem>
<varlistentry>
<term><varname>PROGRAM</varname></term>
<listitem>
- <para>Execute a program to determine whether there
- is a match; the key is true if the program returns
- successfully. The device properties are made available to the
- executed program in the environment. The program's standard output
- is available in the <varname>RESULT</varname> key.</para>
- <para>This can only be used for very short-running foreground tasks. For details,
- see <varname>RUN</varname>.</para>
+ <para>Execute a program to determine whether there is a match; the key is true if the program
+ returns successfully. The device properties are made available to the executed program in the
+ environment. The program's standard output is available in the <varname>RESULT</varname>
+ key.</para>
+
+ <para>This can only be used for very short-running foreground tasks. For details, see
+ <varname>RUN</varname>.</para>
+
+ <para>Note that multiple <varname>PROGRAM</varname> keys may be specified in one rule, and
+ <literal>=</literal>, <literal>:=</literal>, and <literal>+=</literal> have the same effect as
+ <literal>==</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>RUN{<replaceable>type</replaceable>}</varname></term>
<listitem>
- <para>Add a program to the list of programs to be executed after
- processing all the rules for a specific event, depending on
- <literal>type</literal>:</para>
+ <para>Specify a program to be executed after processing of all the rules for the event. With
+ <literal>+=</literal>, this invocation is added to the list, and with <literal>=</literal> or
+ <literal>:=</literal>, it replaces any previous contents of the list. Please note that both
+ <literal>program</literal> and <literal>builtin</literal> types described below use a single
+ list, so clearing the list with <literal>:=</literal> and <literal>=</literal> affects both
+ types.</para>
+
+ <para><replaceable>type</replaceable> may be:</para>
<variablelist>
<varlistentry>
<term><literal>program</literal></term>
</listitem>
</varlistentry>
</variablelist>
- <para>The program name and following arguments are separated by spaces.
- Single quotes can be used to specify arguments with spaces.</para>
- <para>This can only be used for very short-running foreground tasks. Running an
- event process for a long period of time may block all further events for
- this or a dependent device.</para>
- <para>Starting daemons or other long-running processes is not appropriate
- for udev; the forked processes, detached or not, will be unconditionally
- killed after the event handling has finished.</para>
+
+ <para>The program name and following arguments are separated by spaces. Single quotes can be
+ used to specify arguments with spaces.</para>
+
+ <para>This can only be used for very short-running foreground tasks. Running an event process for
+ a long period of time may block all further events for this or a dependent device.</para>
+
+ <para>Note that running programs that access the network or mount/unmount filesystems is not
+ allowed inside of udev rules, due to the default sandbox that is enforced on
+ <filename>systemd-udevd.service</filename>.</para>
+
+ <para>Starting daemons or other long-running processes is not allowed; the forked processes,
+ detached or not, will be unconditionally killed after the event handling has finished. In order
+ to activate long-running processes from udev rules, provide a service unit and pull it in from a
+ udev device using the <varname>SYSTEMD_WANTS</varname> device property. See
+ <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>IMPORT{<replaceable>type</replaceable>}</varname></term>
<listitem>
- <para>Import a set of variables as device properties,
- depending on <literal>type</literal>:</para>
+ <para>Import a set of variables as device properties, depending on
+ <replaceable>type</replaceable>:</para>
+
<variablelist>
<varlistentry>
<term><literal>program</literal></term>
</listitem>
</varlistentry>
</variablelist>
- <para>This can only be used for very short-running foreground tasks. For details
- see <option>RUN</option>.</para>
+
+ <para>This can only be used for very short-running foreground tasks. For details see
+ <option>RUN</option>.</para>
+
+ <para>Note that multiple <varname>IMPORT{}</varname> keys may be specified in one rule, and
+ <literal>=</literal>, <literal>:=</literal>, and <literal>+=</literal> have the same effect as
+ <literal>==</literal>. The key is true if the import is successful, unless <literal>!=</literal>
+ is used as the operator which causes the key to be true if the import failed.</para>
</listitem>
</varlistentry>
<para>Disable the watching of a device node with inotify.</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><option>db_persist</option></term>
+ <listitem>
+ <para>Set the flag (sticky bit) on the udev database entry
+ of the event device. Device properties are then kept in the
+ database even when
+ <command>udevadm info --cleanup-db</command> is called.
+ This option can be useful in certain cases
+ (e.g. Device Mapper devices) for persisting device state
+ on the transition from initramfs.</para>
+ </listitem>
+ </varlistentry>
</variablelist>
</listitem>
</varlistentry>
<varlistentry>
<term><option>$number</option>, <option>%n</option></term>
<listitem>
- <para>The kernel number for this device. For example,
- <literal>sda3</literal> has kernel number <literal>3</literal>.
- </para>
+ <para>The kernel number for this device. For example, <literal>sda3</literal> has kernel number
+ 3.</para>
</listitem>
</varlistentry>
projects / thirdparty / systemd.git / blobdiff