]>
Commit | Line | Data |
---|---|---|
eec575d8 | 1 | <?xml version='1.0'?> <!--*-nxml-*--> |
eec575d8 | 2 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
12b42c76 | 3 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> |
eec575d8 LP |
4 | |
5 | <!-- | |
572eb058 | 6 | SPDX-License-Identifier: LGPL-2.1+ |
eec575d8 LP |
7 | --> |
8 | ||
9 | <refentry id="systemd.device"> | |
798d3a52 ZJS |
10 | <refentryinfo> |
11 | <title>systemd.device</title> | |
12 | <productname>systemd</productname> | |
13 | ||
14 | <authorgroup> | |
15 | <author> | |
16 | <contrib>Developer</contrib> | |
17 | <firstname>Lennart</firstname> | |
18 | <surname>Poettering</surname> | |
19 | <email>lennart@poettering.net</email> | |
20 | </author> | |
21 | </authorgroup> | |
22 | </refentryinfo> | |
23 | ||
24 | <refmeta> | |
25 | <refentrytitle>systemd.device</refentrytitle> | |
26 | <manvolnum>5</manvolnum> | |
27 | </refmeta> | |
28 | ||
29 | <refnamediv> | |
30 | <refname>systemd.device</refname> | |
31 | <refpurpose>Device unit configuration</refpurpose> | |
32 | </refnamediv> | |
33 | ||
34 | <refsynopsisdiv> | |
35 | <para><filename><replaceable>device</replaceable>.device</filename></para> | |
36 | </refsynopsisdiv> | |
37 | ||
38 | <refsect1> | |
39 | <title>Description</title> | |
40 | ||
41 | <para>A unit configuration file whose name ends in | |
42 | <literal>.device</literal> encodes information about a device unit | |
43 | as exposed in the | |
44 | sysfs/<citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> | |
45 | device tree.</para> | |
46 | ||
47 | <para>This unit type has no specific options. See | |
48 | <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> | |
49 | for the common options of all unit configuration files. The common | |
50 | configuration items are configured in the generic | |
51 | <literal>[Unit]</literal> and <literal>[Install]</literal> | |
52 | sections. A separate <literal>[Device]</literal> section does not | |
53 | exist, since no device-specific options may be configured.</para> | |
54 | ||
55 | <para>systemd will dynamically create device units for all kernel | |
56 | devices that are marked with the "systemd" udev tag (by default | |
57 | all block and network devices, and a few others). This may be used | |
58 | to define dependencies between devices and other units. To tag a | |
59 | udev device, use <literal>TAG+="systemd"</literal> in the udev | |
60 | rules file, see | |
61 | <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> | |
62 | for details.</para> | |
63 | ||
64 | <para>Device units are named after the <filename>/sys</filename> | |
65 | and <filename>/dev</filename> paths they control. Example: the | |
66 | device <filename noindex='true'>/dev/sda5</filename> is exposed in | |
67 | systemd as <filename>dev-sda5.device</filename>. For details about | |
68 | the escaping logic used to convert a file system path to a unit | |
69 | name see | |
70 | <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> | |
f332611a JR |
71 | |
72 | <para>Device units will be reloaded by systemd whenever the | |
73 | corresponding device generates a <literal>changed</literal> event. | |
74 | Other units can use <varname>ReloadPropagatedFrom=</varname> to react | |
75 | to that event</para> | |
c129bd5d | 76 | </refsect1> |
798d3a52 | 77 | |
c129bd5d | 78 | <refsect1> |
aed5cb03 | 79 | <title>Automatic Dependencies</title> |
798d3a52 | 80 | |
aed5cb03 ZJS |
81 | <refsect2> |
82 | <title>Implicit Dependencies</title> | |
83 | ||
84 | <para>Many unit types automatically acquire dependencies on device | |
85 | units of devices they require. For example, | |
86 | <filename>.socket</filename> unit acquire dependencies on the | |
87 | device units of the network interface specified in | |
88 | <varname>BindToDevice=</varname>. Similar, swap and mount units | |
89 | acquire dependencies on the units encapsulating their backing | |
90 | block devices.</para> | |
91 | </refsect2> | |
92 | ||
93 | <refsect2> | |
94 | <title>Default Dependencies</title> | |
45f09f93 | 95 | |
aed5cb03 ZJS |
96 | <para>There are no default dependencies for device units.</para> |
97 | </refsect2> | |
45f09f93 JL |
98 | </refsect1> |
99 | ||
798d3a52 ZJS |
100 | <refsect1> |
101 | <title>The udev Database</title> | |
102 | ||
dcebc9ba LP |
103 | <para>Unit settings of device units may either be configured via unit files, or directly from the udev |
104 | database. The following udev device properties are understood by the service manager:</para> | |
798d3a52 ZJS |
105 | |
106 | <variablelist class='udev-directives'> | |
107 | <varlistentry> | |
108 | <term><varname>SYSTEMD_WANTS=</varname></term> | |
109 | <term><varname>SYSTEMD_USER_WANTS=</varname></term> | |
dcebc9ba LP |
110 | <listitem><para>Adds dependencies of type <varname>Wants=</varname> from the device unit to the specified |
111 | units. <varname>SYSTEMD_WANTS=</varname> is read by the system service manager, | |
112 | <varname>SYSTEMD_USER_WANTS=</varname> by user service manager instances. These properties may be used to | |
113 | activate arbitrary units when a specific device becomes available.</para> | |
114 | ||
115 | <para>Note that this and the other udev device properties are not taken into account unless the device is | |
116 | tagged with the <literal>systemd</literal> tag in the udev database, because otherwise the device is not | |
117 | exposed as a systemd unit (see above).</para> | |
118 | ||
119 | <para>Note that systemd will only act on <varname>Wants=</varname> dependencies when a device first becomes | |
120 | active. It will not act on them if they are added to devices that are already active. Use | |
121 | <varname>SYSTEMD_READY=</varname> (see below) to configure when a udev device shall be considered active, and | |
122 | thus when to trigger the dependencies.</para> | |
123 | ||
124 | <!-- Note that we don't document here that we actually apply unit_name_mangle() to all specified names, since | |
125 | that's kinda ugly, and people should instead specify correctly escaped names --> | |
126 | ||
127 | <para>The specified property value should be a space-separated list of valid unit names. If a unit template | |
128 | name is specified (that is, a unit name containing an <literal>@</literal> character indicating a unit name to | |
129 | use for multiple instantiation, but with an empty instance name following the <literal>@</literal>), it will be | |
130 | automatically instantiated by the device's <literal>sysfs</literal> path (that is: the path is escaped and | |
131 | inserted as instance name into the template unit name). This is useful in order to instantiate a specific | |
132 | template unit once for each device that appears and matches specific properties.</para></listitem> | |
798d3a52 ZJS |
133 | </varlistentry> |
134 | ||
135 | <varlistentry> | |
136 | <term><varname>SYSTEMD_ALIAS=</varname></term> | |
137 | <listitem><para>Adds an additional alias name to the device | |
138 | unit. This must be an absolute path that is automatically | |
139 | transformed into a unit name. (See above.)</para></listitem> | |
140 | </varlistentry> | |
141 | ||
142 | <varlistentry> | |
143 | <term><varname>SYSTEMD_READY=</varname></term> | |
dcebc9ba LP |
144 | <listitem><para>If set to 0, systemd will consider this device unplugged even if it shows up in the udev |
145 | tree. If this property is unset or set to 1, the device will be considered plugged if it is visible in the udev | |
146 | tree.</para> | |
147 | ||
148 | <para>This option is useful for devices that initially show up in an uninitialized state in the tree, and for | |
149 | which a <literal>changed</literal> event is generated the moment they are fully set up. Note that | |
150 | <varname>SYSTEMD_WANTS=</varname> (see above) is not acted on as long as <varname>SYSTEMD_READY=0</varname> is | |
151 | set for a device.</para></listitem> | |
798d3a52 ZJS |
152 | </varlistentry> |
153 | ||
154 | <varlistentry> | |
155 | <term><varname>ID_MODEL_FROM_DATABASE=</varname></term> | |
156 | <term><varname>ID_MODEL=</varname></term> | |
157 | ||
158 | <listitem><para>If set, this property is used as description | |
159 | string for the device unit.</para></listitem> | |
160 | </varlistentry> | |
161 | ||
162 | </variablelist> | |
163 | ||
164 | </refsect1> | |
165 | ||
166 | <refsect1> | |
167 | <title>See Also</title> | |
168 | <para> | |
169 | <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, | |
170 | <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, | |
171 | <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, | |
172 | <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>, | |
173 | <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> | |
174 | </para> | |
175 | </refsect1> | |
eec575d8 LP |
176 | |
177 | </refentry> |