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