Systemd/man/systemd-udevd.service.xml

203 lines
8.1 KiB
XML
Raw Normal View History

<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
SPDX-License-Identifier: LGPL-2.1+
-->
<refentry id="systemd-udevd.service"
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
2012-06-26 00:12:00 +02:00
<title>systemd-udevd.service</title>
2012-04-04 14:42:32 +02:00
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>systemd-udevd.service</refentrytitle>
<manvolnum>8</manvolnum>
</refmeta>
<refnamediv>
<refname>systemd-udevd.service</refname>
<refname>systemd-udevd-control.socket</refname>
<refname>systemd-udevd-kernel.socket</refname>
<refname>systemd-udevd</refname>
<refpurpose>Device event managing daemon</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para><filename>systemd-udevd.service</filename></para>
<para><filename>systemd-udevd-control.socket</filename></para>
<para><filename>systemd-udevd-kernel.socket</filename></para>
<cmdsynopsis>
<command>/usr/lib/systemd/systemd-udevd</command>
<arg><option>--daemon</option></arg>
<arg><option>--debug</option></arg>
<arg><option>--children-max=</option></arg>
<arg><option>--exec-delay=</option></arg>
<arg><option>--event-timeout=</option></arg>
<arg><option>--resolve-names=early|late|never</option></arg>
<arg><option>--version</option></arg>
<arg><option>--help</option></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
2012-07-28 23:10:15 +02:00
<para><command>systemd-udevd</command> listens to kernel uevents.
For every event, systemd-udevd executes matching instructions
specified in udev rules. See <citerefentry>
<refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum>
</citerefentry>.</para>
<para>The behavior of the daemon can be configured using
<citerefentry><refentrytitle>udev.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
its command line options, environment variables, and on the kernel
command line, or changed dynamically with <command>udevadm
control</command>.
</para>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>-d</option></term>
<term><option>--daemon</option></term>
<listitem>
<para>Detach and run in the background.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-D</option></term>
<term><option>--debug</option></term>
<listitem>
<para>Print debug messages to standard error.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-c=</option></term>
<term><option>--children-max=</option></term>
<listitem>
2012-07-28 23:10:15 +02:00
<para>Limit the number of events executed in parallel.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-e=</option></term>
<term><option>--exec-delay=</option></term>
<listitem>
<para>Delay the execution of <varname>RUN</varname>
instructions by the given number of seconds. This option
might be useful when debugging system crashes during
coldplug caused by loading non-working kernel
modules.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-t=</option></term>
<term><option>--event-timeout=</option></term>
<listitem>
2014-07-29 15:18:27 +02:00
<para>Set the number of seconds to wait for events to finish. After
this time, the event will be terminated. The default is 180 seconds.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-N=</option></term>
<term><option>--resolve-names=</option></term>
<listitem>
<para>Specify when systemd-udevd should resolve names of users and groups.
When set to <option>early</option> (the default), names will be
resolved when the rules are parsed. When set to
<option>late</option>, names will be resolved for every event.
When set to <option>never</option>, names will never be resolved
and all devices will be owned by root.</para>
</listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="help" />
<xi:include href="standard-options.xml" xpointer="version" />
</variablelist>
</refsect1>
<refsect1><title>Kernel command line</title>
<variablelist class='kernel-commandline-options'>
2012-07-28 23:10:15 +02:00
<para>Parameters starting with "rd." will be read when
<command>systemd-udevd</command> is used in an initrd.</para>
<varlistentry>
util-lib: various improvements to kernel command line parsing This improves kernel command line parsing in a number of ways: a) An kernel option "foo_bar=xyz" is now considered equivalent to "foo-bar-xyz", i.e. when comparing kernel command line option names "-" and "_" are now considered equivalent (this only applies to the option names though, not the option values!). Most of our kernel options used "-" as word separator in kernel command line options so far, but some used "_". With this change, which was a source of confusion for users (well, at least of one user: myself, I just couldn't remember that it's systemd.debug-shell, not systemd.debug_shell). Considering both as equivalent is inspired how modern kernel module loading normalizes all kernel module names to use underscores now too. b) All options previously using a dash for separating words in kernel command line options now use an underscore instead, in all documentation and in code. Since a) has been implemented this should not create any compatibility problems, but normalizes our documentation and our code. c) All kernel command line options which take booleans (or are boolean-like) have been reworked so that "foobar" (without argument) is now equivalent to "foobar=1" (but not "foobar=0"), thus normalizing the handling of our boolean arguments. Specifically this means systemd.debug-shell and systemd_debug_shell=1 are now entirely equivalent. d) All kernel command line options which take an argument, and where no argument is specified will now result in a log message. e.g. passing just "systemd.unit" will no result in a complain that it needs an argument. This is implemented in the proc_cmdline_missing_value() function. e) There's now a call proc_cmdline_get_bool() similar to proc_cmdline_get_key() that parses booleans (following the logic explained in c). f) The proc_cmdline_parse() call's boolean argument has been replaced by a new flags argument that takes a common set of bits with proc_cmdline_get_key(). g) All kernel command line APIs now begin with the same "proc_cmdline_" prefix. h) There are now tests for much of this. Yay!
2016-12-12 18:29:15 +01:00
<term><varname>udev.log_priority=</varname></term>
<term><varname>rd.udev.log_priority=</varname></term>
<listitem>
<para>Set the log level.</para>
</listitem>
</varlistentry>
<varlistentry>
util-lib: various improvements to kernel command line parsing This improves kernel command line parsing in a number of ways: a) An kernel option "foo_bar=xyz" is now considered equivalent to "foo-bar-xyz", i.e. when comparing kernel command line option names "-" and "_" are now considered equivalent (this only applies to the option names though, not the option values!). Most of our kernel options used "-" as word separator in kernel command line options so far, but some used "_". With this change, which was a source of confusion for users (well, at least of one user: myself, I just couldn't remember that it's systemd.debug-shell, not systemd.debug_shell). Considering both as equivalent is inspired how modern kernel module loading normalizes all kernel module names to use underscores now too. b) All options previously using a dash for separating words in kernel command line options now use an underscore instead, in all documentation and in code. Since a) has been implemented this should not create any compatibility problems, but normalizes our documentation and our code. c) All kernel command line options which take booleans (or are boolean-like) have been reworked so that "foobar" (without argument) is now equivalent to "foobar=1" (but not "foobar=0"), thus normalizing the handling of our boolean arguments. Specifically this means systemd.debug-shell and systemd_debug_shell=1 are now entirely equivalent. d) All kernel command line options which take an argument, and where no argument is specified will now result in a log message. e.g. passing just "systemd.unit" will no result in a complain that it needs an argument. This is implemented in the proc_cmdline_missing_value() function. e) There's now a call proc_cmdline_get_bool() similar to proc_cmdline_get_key() that parses booleans (following the logic explained in c). f) The proc_cmdline_parse() call's boolean argument has been replaced by a new flags argument that takes a common set of bits with proc_cmdline_get_key(). g) All kernel command line APIs now begin with the same "proc_cmdline_" prefix. h) There are now tests for much of this. Yay!
2016-12-12 18:29:15 +01:00
<term><varname>udev.children_max=</varname></term>
<term><varname>rd.udev.children_max=</varname></term>
<listitem>
2012-07-28 23:10:15 +02:00
<para>Limit the number of events executed in parallel.</para>
</listitem>
</varlistentry>
<varlistentry>
util-lib: various improvements to kernel command line parsing This improves kernel command line parsing in a number of ways: a) An kernel option "foo_bar=xyz" is now considered equivalent to "foo-bar-xyz", i.e. when comparing kernel command line option names "-" and "_" are now considered equivalent (this only applies to the option names though, not the option values!). Most of our kernel options used "-" as word separator in kernel command line options so far, but some used "_". With this change, which was a source of confusion for users (well, at least of one user: myself, I just couldn't remember that it's systemd.debug-shell, not systemd.debug_shell). Considering both as equivalent is inspired how modern kernel module loading normalizes all kernel module names to use underscores now too. b) All options previously using a dash for separating words in kernel command line options now use an underscore instead, in all documentation and in code. Since a) has been implemented this should not create any compatibility problems, but normalizes our documentation and our code. c) All kernel command line options which take booleans (or are boolean-like) have been reworked so that "foobar" (without argument) is now equivalent to "foobar=1" (but not "foobar=0"), thus normalizing the handling of our boolean arguments. Specifically this means systemd.debug-shell and systemd_debug_shell=1 are now entirely equivalent. d) All kernel command line options which take an argument, and where no argument is specified will now result in a log message. e.g. passing just "systemd.unit" will no result in a complain that it needs an argument. This is implemented in the proc_cmdline_missing_value() function. e) There's now a call proc_cmdline_get_bool() similar to proc_cmdline_get_key() that parses booleans (following the logic explained in c). f) The proc_cmdline_parse() call's boolean argument has been replaced by a new flags argument that takes a common set of bits with proc_cmdline_get_key(). g) All kernel command line APIs now begin with the same "proc_cmdline_" prefix. h) There are now tests for much of this. Yay!
2016-12-12 18:29:15 +01:00
<term><varname>udev.exec_delay=</varname></term>
<term><varname>rd.udev.exec_delay=</varname></term>
<listitem>
<para>Delay the execution of <varname>RUN</varname> instructions by the given
2012-07-28 23:10:15 +02:00
number of seconds. This option might be useful when
debugging system crashes during coldplug caused by loading
non-working kernel modules.</para>
</listitem>
</varlistentry>
<varlistentry>
util-lib: various improvements to kernel command line parsing This improves kernel command line parsing in a number of ways: a) An kernel option "foo_bar=xyz" is now considered equivalent to "foo-bar-xyz", i.e. when comparing kernel command line option names "-" and "_" are now considered equivalent (this only applies to the option names though, not the option values!). Most of our kernel options used "-" as word separator in kernel command line options so far, but some used "_". With this change, which was a source of confusion for users (well, at least of one user: myself, I just couldn't remember that it's systemd.debug-shell, not systemd.debug_shell). Considering both as equivalent is inspired how modern kernel module loading normalizes all kernel module names to use underscores now too. b) All options previously using a dash for separating words in kernel command line options now use an underscore instead, in all documentation and in code. Since a) has been implemented this should not create any compatibility problems, but normalizes our documentation and our code. c) All kernel command line options which take booleans (or are boolean-like) have been reworked so that "foobar" (without argument) is now equivalent to "foobar=1" (but not "foobar=0"), thus normalizing the handling of our boolean arguments. Specifically this means systemd.debug-shell and systemd_debug_shell=1 are now entirely equivalent. d) All kernel command line options which take an argument, and where no argument is specified will now result in a log message. e.g. passing just "systemd.unit" will no result in a complain that it needs an argument. This is implemented in the proc_cmdline_missing_value() function. e) There's now a call proc_cmdline_get_bool() similar to proc_cmdline_get_key() that parses booleans (following the logic explained in c). f) The proc_cmdline_parse() call's boolean argument has been replaced by a new flags argument that takes a common set of bits with proc_cmdline_get_key(). g) All kernel command line APIs now begin with the same "proc_cmdline_" prefix. h) There are now tests for much of this. Yay!
2016-12-12 18:29:15 +01:00
<term><varname>udev.event_timeout=</varname></term>
<term><varname>rd.udev.event_timeout=</varname></term>
<listitem>
<para>Wait for events to finish up to the given number
of seconds. This option might be useful if events are
2014-07-29 15:18:27 +02:00
terminated due to kernel drivers taking too long to initialize.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>net.ifnames=</varname></term>
<listitem>
<para>Network interfaces are renamed to give them predictable names
when possible. It is enabled by default; specifying 0 disables it.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>net.naming-scheme=</varname></term>
<listitem>
<para>Network interfaces are renamed to give them predictable names when possible (unless
<varname>net.ifnames=0</varname> is specified, see above). The names are derived from various device metadata
fields. Newer versions of <filename>systemd-udevd.service</filename> take more of these fields into account,
improving (and thus possibly changing) the names used for the same devices. With this kernel command line
option it is possible to pick a specific version of this algorithm. It expects a naming scheme identifier as
argument. Currently the following identifiers are known: <literal>v238</literal>, <literal>v239</literal>,
<literal>v240</literal> which each implement the naming scheme that was the default in the indicated systemd
version. Note that selecting a specific scheme is not sufficient to fully stabilize interface naming: the
naming is generally derived from driver attributes exposed by the kernel. As the kernel is updated,
previously missing attributes <filename>systemd-udevd.service</filename> is checking might appear, which
affects older name derivation algorithms, too.</para>
</listitem>
</varlistentry>
</variablelist>
<!-- when adding entries here, consider also adding them
in kernel-command-line.xml -->
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>udev.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>