2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
6 SPDX-License-Identifier: LGPL-2.1-or-later
7 Copyright © 2014 Jason St. John
10 <refentry id=
"udev" xmlns:
xi=
"http://www.w3.org/2001/XInclude">
13 <productname>systemd
</productname>
17 <refentrytitle>udev
</refentrytitle>
18 <manvolnum>7</manvolnum>
22 <refname>udev
</refname>
23 <refpurpose>Dynamic device management
</refpurpose>
27 <title>Description
</title>
28 <para>udev supplies the system software with device events, manages permissions
29 of device nodes and may create additional symlinks in the
<filename>/dev/
</filename>
30 directory, or renames network interfaces. The kernel usually just assigns unpredictable
31 device names based on the order of discovery. Meaningful symlinks or network device
32 names provide a way to reliably identify devices based on their properties or
33 current configuration.
</para>
35 <para>The udev daemon,
<citerefentry><refentrytitle>systemd-udevd.service
</refentrytitle>
36 <manvolnum>8</manvolnum></citerefentry>, receives device uevents directly from
37 the kernel whenever a device is added or removed from the system, or it changes its
38 state. When udev receives a device event, it matches its configured set of rules
39 against various device attributes to identify the device. Rules that match may
40 provide additional device information to be stored in the udev database or
41 to be used to create meaningful symlink names.
</para>
43 <para>All device information udev processes is stored in the udev database and
44 sent out to possible event subscribers. Access to all stored data and the event
45 sources is provided by the library libudev.
</para>
49 <title>Rules Files
</title>
50 <para>The udev rules are read from the files located in the system rules directories
51 <filename>/usr/lib/udev/rules.d
</filename> and
<filename>/usr/local/lib/udev/rules.d
</filename>, the
52 volatile runtime directory
<filename>/run/udev/rules.d
</filename> and the local administration
53 directory
<filename>/etc/udev/rules.d
</filename>. All rules files are collectively sorted and
54 processed in lexical order, regardless of the directories in which they live. However, files with
55 identical filenames replace each other. Files in
<filename>/etc/
</filename> have the highest priority,
56 files in
<filename>/run/
</filename> take precedence over files with the same name under
57 <filename>/usr/
</filename>. This can be used to override a system-supplied rules file with a local
58 file if needed; a symlink in
<filename>/etc/
</filename> with the same name as a rules file in
59 <filename>/usr/lib/
</filename>, pointing to
<filename>/dev/null
</filename>, disables the rules file
60 entirely. Rule files must have the extension
<filename>.rules
</filename>; other extensions are
63 <para>Every line in the rules file contains at least one key-value pair.
64 Except for empty lines or lines beginning with
<literal>#
</literal>, which are ignored.
65 There are two kinds of keys: match and assignment.
66 If all match keys match against their values, the rule gets applied and the
67 assignment keys get the specified values assigned.
</para>
69 <para>A matching rule may rename a network interface, add symlinks
70 pointing to the device node, or run a specified program as part of
71 the event handling.
</para>
73 <para>A rule consists of a comma-separated list of one or more key-operator-value expressions.
74 Each expression has a distinct effect, depending on the key and operator used.
</para>
77 <title>Operators
</title>
80 <term><literal>==
</literal></term>
82 <para>Compare for equality. (The specified key has the specified value.)
</para>
87 <term><literal>!=
</literal></term>
89 <para>Compare for inequality. (The specified key doesn't have the specified value, or the
90 specified key is not present at all.)
96 <term><literal>=
</literal></term>
98 <para>Assign a value to a key. Keys that represent a list are reset
99 and only this single value is assigned.
</para>
104 <term><literal>+=
</literal></term>
106 <para>Add the value to a key that holds a list of entries.
</para>
111 <term><literal>-=
</literal></term>
113 <para>Remove the value from a key that holds a list of entries.
</para>
115 <xi:include href=
"version-info.xml" xpointer=
"v217"/>
120 <term><literal>:=
</literal></term>
122 <para>Assign a value to a key finally; disallow any later changes.
</para>
124 <xi:include href=
"version-info.xml" xpointer=
"v247"/>
131 <title>Values
</title>
132 <para>Values are written as double quoted strings, such as (
"string").
133 To include a quotation mark (
") in the value, precede it by a backslash (\").
134 Any other occurrences of a backslash followed by a character are not unescaped.
135 That is,
"\t\n" is treated as four characters:
136 backslash, lowercase t, backslash, lowercase n.
</para>
138 <para>The string can be prefixed with a lowercase e (e
"string\n") to mark the string as
140 <ulink url=
"https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">Escape sequences in C
</ulink>.
141 For example, e
"string\n" is parsed as
7 characters:
6 lowercase letters and a newline.
142 This can be useful for writing special characters when a kernel driver requires them.
</para>
144 <para>Please note that
<constant>NUL
</constant> is not allowed in either string variant.
</para>
149 <para>The following key names can be used to match against device properties.
150 Some of the keys also match against properties of the parent devices in sysfs,
151 not only the device that has generated the event. If multiple keys that match
152 a parent device are specified in a single rule, all these keys must match at
153 one and the same parent device.
</para>
154 <variablelist class='udev-directives'
>
156 <term><varname>ACTION
</varname></term>
158 <para>Match the name of the event action.
</para>
163 <term><varname>DEVPATH
</varname></term>
165 <para>Match the devpath of the event device.
</para>
170 <term><varname>KERNEL
</varname></term>
172 <para>Match the name of the event device.
</para>
177 <term><varname>KERNELS
</varname></term>
179 <para>Search the devpath upwards for a matching device name.
</para>
184 <term><varname>NAME
</varname></term>
186 <para>Match the name of a network interface. It can be used once the
187 NAME key has been set in one of the preceding rules.
</para>
192 <term><varname>SYMLINK
</varname></term>
194 <para>Match the name of a symlink targeting the node. It can be used once a SYMLINK key has
195 been set in one of the preceding rules. There may be multiple symlinks; only one needs to
196 match. If the operator is
<literal>!=
</literal>, the token returns true only if there is no
197 symlink matched.
</para>
202 <term><varname>SUBSYSTEM
</varname></term>
204 <para>Match the subsystem of the event device.
</para>
209 <term><varname>SUBSYSTEMS
</varname></term>
211 <para>Search the devpath upwards for a matching device subsystem name.
</para>
216 <term><varname>DRIVER
</varname></term>
218 <para>Match the driver name of the event device. Only set this key for devices
219 which are bound to a driver at the time the event is generated.
</para>
224 <term><varname>DRIVERS
</varname></term>
226 <para>Search the devpath upwards for a matching device driver name.
</para>
231 <term><varname>ATTR{
<replaceable>filename
</replaceable>}
</varname></term>
233 <para>Match sysfs attribute value of the event device.
</para>
235 <para>Trailing whitespace in the attribute values is ignored unless the specified match value
236 itself contains trailing whitespace.
</para>
241 <term><varname>ATTRS{
<replaceable>filename
</replaceable>}
</varname></term>
243 <para>Search the devpath upwards for a device with matching sysfs attribute values. If
244 multiple
<varname>ATTRS
</varname> matches are specified, all of them must match on the same
247 <para>Trailing whitespace in the attribute values is ignored unless the specified match value
248 itself contains trailing whitespace.
</para>
253 <term><varname>SYSCTL{
<replaceable>kernel parameter
</replaceable>}
</varname></term>
255 <para>Match a kernel parameter value.
</para>
257 <xi:include href=
"version-info.xml" xpointer=
"v240"/>
262 <term><varname>ENV{
<replaceable>key
</replaceable>}
</varname></term>
264 <para>Match against a device property value.
</para>
269 <term><varname>CONST{
<replaceable>key
</replaceable>}
</varname></term>
271 <para>Match against a system-wide constant. Supported keys are:
</para>
274 <term><literal>arch
</literal></term>
276 <para>System's architecture. See
<option>ConditionArchitecture=
</option> in
277 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
278 for possible values.
</para>
280 <xi:include href=
"version-info.xml" xpointer=
"v244"/>
284 <term><literal>virt
</literal></term>
286 <para>System's virtualization environment. See
287 <citerefentry><refentrytitle>systemd-detect-virt
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
288 for possible values.
</para>
290 <xi:include href=
"version-info.xml" xpointer=
"v244"/>
294 <term><literal>cvm
</literal></term>
296 <para>System's confidential virtualization technology. See
297 <citerefentry><refentrytitle>systemd-detect-virt
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
298 for possible values.
</para>
300 <xi:include href=
"version-info.xml" xpointer=
"v254"/>
304 <para>Unknown keys will never match.
</para>
306 <xi:include href=
"version-info.xml" xpointer=
"v244"/>
311 <term><varname>TAG
</varname></term>
313 <para>Match against one of device tags. It can be used once a TAG key has been set in one of
314 the preceding rules. There may be multiple tags; only one needs to match. If the operator is
315 <literal>!=
</literal>, the token returns true only if there is no tag matched.
</para>
320 <term><varname>TAGS
</varname></term>
322 <para>Search the devpath upwards for a device with matching tag. If the operator is
323 <literal>!=
</literal>, the token returns true only if there is no tag matched.
</para>
328 <term><varname>TEST{
<replaceable>octal mode mask
</replaceable>}
</varname></term>
330 <para>Test the existence of a file. An octal mode mask can be specified
336 <term><varname>PROGRAM
</varname></term>
338 <para>Execute a program to determine whether there is a match; the key is true if the program
339 returns successfully. The device properties are made available to the executed program in the
340 environment. The program's standard output is available in the
<varname>RESULT
</varname>
343 <para>This can only be used for very short-running foreground tasks. For details, see
344 <varname>RUN
</varname>.
</para>
346 <para>Note that multiple
<varname>PROGRAM
</varname> keys may be specified in one rule, and
347 <literal>=
</literal>,
<literal>:=
</literal>, and
<literal>+=
</literal> have the same effect as
348 <literal>==
</literal>.
</para>
353 <term><varname>RESULT
</varname></term>
355 <para>Match the returned string of the last
<varname>PROGRAM
</varname> call.
356 This key can be used in the same or in any later rule after a
357 <varname>PROGRAM
</varname> call.
</para>
362 <para>Most of the fields support shell glob pattern matching and
363 alternate patterns. The following special characters are supported:
</para>
366 <term><literal>*
</literal></term>
368 <para>Matches zero or more characters.
</para>
372 <term><literal>?
</literal></term>
374 <para>Matches any single character.
</para>
378 <term><literal>[]
</literal></term>
380 <para>Matches any single character specified within the brackets. For
381 example, the pattern string
<literal>tty[SR]
</literal>
382 would match either
<literal>ttyS
</literal> or
<literal>ttyR
</literal>.
383 Ranges are also supported via the
<literal>-
</literal> character.
384 For example, to match on the range of all digits, the pattern
385 <literal>[
0-
9]
</literal> could be used. If the first character
386 following the
<literal>[
</literal> is a
<literal>!
</literal>,
387 any characters not enclosed are matched.
</para>
391 <term><literal>|
</literal></term>
393 <para>Separates alternative patterns. For example, the pattern string
394 <literal>abc|x*
</literal> would match either
<literal>abc
</literal>
395 or
<literal>x*
</literal>.
</para>
397 <xi:include href=
"version-info.xml" xpointer=
"v217"/>
402 <para>The following keys can get values assigned:
</para>
403 <variablelist class='udev-directives'
>
405 <term><varname>NAME
</varname></term>
407 <para>The name to use for a network interface. See
408 <citerefentry><refentrytitle>systemd.link
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
409 for a higher-level mechanism for setting the interface name.
410 The name of a device node cannot be changed by udev, only additional
411 symlinks can be created.
</para>
416 <term><varname>SYMLINK
</varname></term>
418 <para>The name of a symlink targeting the node. Every matching rule adds
419 this value to the list of symlinks to be created.
</para>
420 <para>The set of characters to name a symlink is limited. Allowed
421 characters are
<literal>0-
9A-Za-z#+-.:=@_/
</literal>, valid UTF-
8 character
422 sequences, and
<literal>\x00
</literal> hex encoding. All other
423 characters are replaced by a
<literal>_
</literal> character.
</para>
424 <para>Multiple symlinks may be specified by separating the names by the
425 space character. In case multiple devices claim the same name, the link
426 always points to the device with the highest link_priority. If the current
427 device goes away, the links are re-evaluated and the device with the
428 next highest link_priority becomes the owner of the link. If no
429 link_priority is specified, the order of the devices (and which one of
430 them owns the link) is undefined.
</para>
431 <para>Symlink names must never conflict with the kernel's default device
432 node names, as that would result in unpredictable behavior.
438 <term><varname>OWNER
</varname>,
<varname>GROUP
</varname>,
<varname>MODE
</varname></term>
440 <para>The permissions for the device node. Every specified value overrides
441 the compiled-in default value.
</para>
446 <term><varname>SECLABEL{
<replaceable>module
</replaceable>}
</varname></term>
448 <para>Applies the specified Linux Security Module label to the device node.
</para>
450 <xi:include href=
"version-info.xml" xpointer=
"v209"/>
455 <term><varname>ATTR{
<replaceable>key
</replaceable>}
</varname></term>
457 <para>The value that should be written to a sysfs attribute of the
463 <term><varname>SYSCTL{
<replaceable>kernel parameter
</replaceable>}
</varname></term>
465 <para>The value that should be written to kernel parameter.
</para>
467 <xi:include href=
"version-info.xml" xpointer=
"v220"/>
472 <term><varname>ENV{
<replaceable>key
</replaceable>}
</varname></term>
474 <para>Set a device property value. Property names with a leading
<literal>.
</literal>
475 are neither stored in the database nor exported to events or
476 external tools (run by, for example, the
<varname>PROGRAM
</varname>
482 <term><varname>TAG
</varname></term>
484 <para>Attach a tag to a device. This is used to filter events for users
485 of libudev's monitor functionality, or to enumerate a group of tagged
486 devices. The implementation can only work efficiently if only a few
487 tags are attached to a device. It is only meant to be used in
488 contexts with specific device filter requirements, and not as a
489 general-purpose flag. Excessive use might result in inefficient event
495 <term><varname>RUN{
<replaceable>type
</replaceable>}
</varname></term>
497 <para>Specify a program to be executed after processing of all the rules for the event. With
498 <literal>+=
</literal>, this invocation is added to the list, and with
<literal>=
</literal> or
499 <literal>:=
</literal>, it replaces any previous contents of the list. Please note that both
500 <literal>program
</literal> and
<literal>builtin
</literal> types described below share a common
501 list, so clearing the list with
<literal>:=
</literal> and
<literal>=
</literal> affects both
504 <para><replaceable>type
</replaceable> may be:
</para>
507 <term><literal>program
</literal></term>
509 <para>Execute an external program specified as the assigned
510 value. If no absolute path is given, the program is expected
511 to live in
<filename>/usr/lib/udev
</filename>; otherwise, the
512 absolute path must be specified.
</para>
513 <para>This is the default if no
<replaceable>type
</replaceable>
518 <term><literal>builtin
</literal></term>
520 <para>As
<varname>program
</varname>, but use one of the
521 built-in programs rather than an external one.
</para>
523 <xi:include href=
"version-info.xml" xpointer=
"v199"/>
528 <para>The program name and following arguments are separated by spaces. Single quotes can be
529 used to specify arguments with spaces.
</para>
531 <para>This can only be used for very short-running foreground tasks. Running an event process for
532 a long period of time may block all further events for this or a dependent device.
</para>
534 <para>Note that running programs that access the network or mount/unmount filesystems is not
535 allowed inside of udev rules, due to the default sandbox that is enforced on
536 <filename>systemd-udevd.service
</filename>.
</para>
538 <para>Starting daemons or other long-running processes is not allowed; the forked processes,
539 detached or not, will be unconditionally killed after the event handling has finished. In order
540 to activate long-running processes from udev rules, provide a service unit and pull it in from a
541 udev device using the
<varname>SYSTEMD_WANTS
</varname> device property. See
542 <citerefentry><refentrytitle>systemd.device
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
548 <term><varname>LABEL
</varname></term>
550 <para>A named label to which a
<varname>GOTO
</varname> may jump.
</para>
555 <term><varname>GOTO
</varname></term>
557 <para>Jumps to the next
<varname>LABEL
</varname> with a matching name.
</para>
562 <term><varname>IMPORT{
<replaceable>type
</replaceable>}
</varname></term>
564 <para>Import a set of variables as device properties, depending on
565 <replaceable>type
</replaceable>:
</para>
569 <term><literal>program
</literal></term>
571 <para>Execute an external program specified as the assigned
572 value and, if it returns successfully,
573 import its output, which must be in environment key
574 format. Path specification, command/argument separation,
575 and quoting work like in
<varname>RUN
</varname>.
</para>
577 <xi:include href=
"version-info.xml" xpointer=
"v199"/>
581 <term><literal>builtin
</literal></term>
583 <para>Similar to
<literal>program
</literal>, but use one of the
584 built-in programs rather than an external one.
</para>
586 <xi:include href=
"version-info.xml" xpointer=
"v199"/>
590 <term><literal>file
</literal></term>
592 <para>Import a text file specified as the assigned value, the content
593 of which must be in environment key format.
</para>
597 <term><literal>db
</literal></term>
599 <para>Import a single property specified as the assigned value from the
600 current device database. This works only if the database is already populated
601 by an earlier event.
</para>
605 <term><literal>cmdline
</literal></term>
607 <para>Import a single property from the kernel command line. For simple flags
608 the value of the property is set to
<literal>1</literal>.
</para>
612 <term><literal>parent
</literal></term>
614 <para>Import the stored keys from the parent device by reading
615 the database entry of the parent device. The value assigned to
616 <option>IMPORT{parent}
</option> is used as a filter of key names
617 to import (with the same shell glob pattern matching used for
623 <para>This can only be used for very short-running foreground tasks. For details see
624 <option>RUN
</option>.
</para>
626 <para>Note that multiple
<varname>IMPORT{}
</varname> keys may be specified in one rule, and
627 <literal>=
</literal>,
<literal>:=
</literal>, and
<literal>+=
</literal> have the same effect as
628 <literal>==
</literal>. The key is true if the import is successful, unless
<literal>!=
</literal>
629 is used as the operator which causes the key to be true if the import failed.
</para>
634 <term><varname>OPTIONS
</varname></term>
636 <para>Rule and device options:
</para>
637 <variablelist class='udev-directives'
>
639 <term><option>link_priority=
<replaceable>value
</replaceable></option></term>
641 <para>Specify the priority of the created symlinks. Devices with higher
642 priorities overwrite existing symlinks of other devices. The default is
0.
</para>
646 <term><option>string_escape=
<replaceable>none|replace
</replaceable></option></term>
648 <para>When
<literal>replace
</literal>, possibly unsafe characters in strings
649 assigned to
<varname>NAME
</varname>,
<varname>SYMLINK
</varname>, and
650 <varname>ENV{
<replaceable>key
</replaceable>}
</varname> are replaced. When
651 <literal>none
</literal>, no replacement is performed. When unset, the replacement
652 is performed for
<varname>NAME
</varname>,
<varname>SYMLINK
</varname>, but not for
653 <varname>ENV{
<replaceable>key
</replaceable>}
</varname>. Defaults to unset.
</para>
657 <term><option>static_node=
</option></term>
659 <para>Apply the permissions specified in this rule to the
660 static device node with the specified name. Also, for every
661 tag specified in this rule, create a symlink
663 <filename>/run/udev/static_node-tags/
<replaceable>tag
</replaceable></filename>
664 pointing at the static device node with the specified name.
665 Static device node creation is performed by systemd-tmpfiles
666 before systemd-udevd is started. The static nodes might not
667 have a corresponding kernel device; they are used to trigger
668 automatic kernel module loading when they are accessed.
</para>
672 <term><option>watch
</option></term>
674 <para>Watch the device node with inotify; when the node is
675 closed after being opened for writing, a change uevent is
680 <term><option>nowatch
</option></term>
682 <para>Disable the watching of a device node with inotify.
</para>
686 <term><option>db_persist
</option></term>
688 <para>Set the flag (sticky bit) on the udev database entry of the event device. Device
689 properties are then kept in the database even when
<command>udevadm info
690 --cleanup-db
</command> is called. This option can be useful in certain cases
691 (e.g. Device Mapper devices) for persisting device state on the transition from
694 <xi:include href=
"version-info.xml" xpointer=
"v241"/>
698 <term><option>log_level=
<replaceable>level
</replaceable></option></term>
700 <para>Takes a log level name like
<literal>debug
</literal> or
701 <literal>info
</literal>, or a special value
<literal>reset
</literal>. When a log
702 level name is specified, the maximum log level is changed to that level. When
703 <literal>reset
</literal> is set, then the previously specified log level is
704 revoked. Defaults to the log level of the main process of
705 <command>systemd-udevd
</command>.
</para>
706 <para>This may be useful when debugging events for certain devices. Note that the
707 log level is applied when the line including this rule is processed. So, for
708 debugging, it is recommended that this is specified at earlier place, e.g., the
709 first line of
<filename>00-debug.rules
</filename>.
</para>
710 <para>Example for debugging uevent processing for network interfaces:
711 <programlisting># /etc/udev/rules.d/
00-debug-net.rules
712 SUBSYSTEM==
"net",
OPTIONS=
"log_level=debug"</programlisting></para>
714 <xi:include href=
"version-info.xml" xpointer=
"v248"/>
722 <para>The
<varname>ENV
</varname>,
<varname>GROUP
</varname>,
723 <varname>MODE
</varname>,
<varname>NAME
</varname>,
724 <varname>OWNER
</varname>,
<varname>PROGRAM
</varname>,
725 <varname>RUN
</varname>,
<varname>SECLABEL
</varname>, and
726 <varname>SYMLINK
</varname> fields support simple string substitutions.
727 The
<varname>RUN
</varname> substitutions are performed after all rules
728 have been processed, right before the program is executed, allowing for
729 the use of device properties set by earlier matching rules. For all
730 other fields, substitutions are performed while the individual rule is
731 being processed. The available substitutions are:
</para>
732 <variablelist class='udev-directives'
>
734 <term><option>$kernel
</option>,
<option>%k
</option></term>
736 <para>The kernel name for this device.
</para>
741 <term><option>$number
</option>,
<option>%n
</option></term>
743 <para>The kernel number for this device. For example,
<literal>sda3
</literal> has kernel number
749 <term><option>$devpath
</option>,
<option>%p
</option></term>
751 <para>The devpath of the device.
</para>
756 <term><option>$id
</option>,
<option>%b
</option></term>
758 <para>The name of the device matched while searching the devpath
759 upwards for
<option>SUBSYSTEMS
</option>,
<option>KERNELS
</option>,
760 <option>DRIVERS
</option>, and
<option>ATTRS
</option>.
766 <term><option>$driver
</option></term>
768 <para>The driver name of the device matched while searching the
769 devpath upwards for
<option>SUBSYSTEMS
</option>,
770 <option>KERNELS
</option>,
<option>DRIVERS
</option>, and
771 <option>ATTRS
</option>.
777 <term><option>$attr{
<replaceable>file
</replaceable>}
</option>,
<option>%s{
<replaceable>file
</replaceable>}
</option></term>
779 <para>The value of a sysfs attribute found at the device where
780 all keys of the rule have matched. If the matching device does not
781 have such an attribute, and a previous
<option>KERNELS
</option>,
782 <option>SUBSYSTEMS
</option>,
<option>DRIVERS
</option>, or
783 <option>ATTRS
</option> test selected a parent device, then the
784 attribute from that parent device is used.
786 <para>If the attribute is a symlink, the last element of the
787 symlink target is returned as the value.
793 <term><option>$env{
<replaceable>key
</replaceable>}
</option>,
<option>%E{
<replaceable>key
</replaceable>}
</option></term>
795 <para>A device property value.
</para>
800 <term><option>$major
</option>,
<option>%M
</option></term>
802 <para>The kernel major number for the device.
</para>
807 <term><option>$minor
</option>,
<option>%m
</option></term>
809 <para>The kernel minor number for the device.
</para>
814 <term><option>$result
</option>,
<option>%c
</option></term>
816 <para>The string returned by the external program requested with
817 <varname>PROGRAM
</varname>.
818 A single part of the string, separated by a space character, may be selected
819 by specifying the part number as an attribute:
<literal>%c{N}
</literal>.
820 If the number is followed by the
<literal>+
</literal> character, this part plus all remaining parts
821 of the result string are substituted:
<literal>%c{N+}
</literal>.
</para>
826 <term><option>$parent
</option>,
<option>%P
</option></term>
828 <para>The node name of the parent device.
</para>
833 <term><option>$name
</option></term>
835 <para>The current name of the device. If not changed by a rule, it is the
836 name of the kernel device.
</para>
841 <term><option>$links
</option></term>
843 <para>A space-separated list of the current symlinks. The value is
844 only set during a remove event or if an earlier rule assigned a value.
</para>
849 <term><option>$root
</option>,
<option>%r
</option></term>
851 <para>The udev_root value.
</para>
856 <term><option>$sys
</option>,
<option>%S
</option></term>
858 <para>The sysfs mount point.
</para>
863 <term><option>$devnode
</option>,
<option>%N
</option></term>
865 <para>The name of the device node.
</para>
870 <term><option>%%
</option></term>
872 <para>The
<literal>%
</literal> character itself.
</para>
877 <term><option>$$
</option></term>
879 <para>The
<literal>$
</literal> character itself.
</para>
887 <title>See Also
</title>
888 <para><simplelist type=
"inline">
889 <member><citerefentry>
890 <refentrytitle>systemd-udevd.service
</refentrytitle><manvolnum>8</manvolnum>
891 </citerefentry></member>
892 <member><citerefentry>
893 <refentrytitle>udevadm
</refentrytitle><manvolnum>8</manvolnum>
894 </citerefentry></member>
895 <member><citerefentry>
896 <refentrytitle>systemd.link
</refentrytitle><manvolnum>5</manvolnum>
897 </citerefentry></member>