]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd.generator.xml
man: standarize on one-line license header
[thirdparty/systemd.git] / man / systemd.generator.xml
1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
4 <!ENTITY % entities SYSTEM "custom-entities.ent" >
5 %entities;
6 ]>
7 <!-- SPDX-License-Identifier: LGPL-2.1+ -->
8
9 <refentry id="systemd.generator">
10 <refentryinfo>
11 <title>systemd.generator</title>
12 <productname>systemd</productname>
13 </refentryinfo>
14
15 <refmeta>
16 <refentrytitle>systemd.generator</refentrytitle>
17 <manvolnum>7</manvolnum>
18 </refmeta>
19
20 <refnamediv>
21 <refname>systemd.generator</refname>
22 <refpurpose>systemd unit generators</refpurpose>
23 </refnamediv>
24
25 <refsynopsisdiv>
26 <cmdsynopsis>
27 <command>/path/to/generator</command>
28 <arg choice="plain"><replaceable>normal-dir</replaceable></arg>
29 <arg choice="plain"><replaceable>early-dir</replaceable></arg>
30 <arg choice="plain"><replaceable>late-dir</replaceable></arg>
31 </cmdsynopsis>
32
33 <para>
34 <literallayout><filename>/run/systemd/system-generators/*</filename>
35 <filename>/etc/systemd/system-generators/*</filename>
36 <filename>/usr/local/lib/systemd/system-generators/*</filename>
37 <filename>&systemgeneratordir;/*</filename></literallayout>
38 </para>
39
40 <para>
41 <literallayout><filename>/run/systemd/user-generators/*</filename>
42 <filename>/etc/systemd/user-generators/*</filename>
43 <filename>/usr/local/lib/systemd/user-generators/*</filename>
44 <filename>&usergeneratordir;/*</filename></literallayout>
45 </para>
46 </refsynopsisdiv>
47
48 <refsect1>
49 <title>Description</title>
50 <para>Generators are small executables that live in
51 <filename>&systemgeneratordir;/</filename> and other directories listed above.
52 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
53 will execute those binaries very early at bootup and at configuration reload time
54 — before unit files are loaded. Their main purpose is to convert configuration
55 that is not native into dynamically generated unit files.</para>
56
57 <para>Each generator is called with three directory paths that are to be used for
58 generator output. In these three directories, generators may dynamically generate
59 unit files (regular ones, instances, as well as templates), unit file
60 <filename>.d/</filename> drop-ins, and create symbolic links to unit files to add
61 additional dependencies, create aliases, or instantiate existing templates. Those
62 directories are included in the unit load path of
63 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
64 allowing generated configuration to extend or override existing
65 definitions.</para>
66
67 <para>Directory paths for generator output differ by priority:
68 <filename>…/generator.early</filename> has priority higher than the admin
69 configuration in <filename>/etc</filename>, while
70 <filename>…/generator</filename> has lower priority than
71 <filename>/etc</filename> but higher than vendor configuration in
72 <filename>/usr</filename>, and <filename>…/generator.late</filename> has priority
73 lower than all other configuration. See the next section and the discussion of
74 unit load paths and unit overriding in
75 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
76 </para>
77
78 <para>Generators are loaded from a set of paths determined during
79 compilation, as listed above. System and user generators are loaded
80 from directories with names ending in
81 <filename>system-generators/</filename> and
82 <filename>user-generators/</filename>, respectively. Generators
83 found in directories listed earlier override the ones with the
84 same name in directories lower in the list. A symlink to
85 <filename>/dev/null</filename> or an empty file can be used to
86 mask a generator, thereby preventing it from running. Please note
87 that the order of the two directories with the highest priority is
88 reversed with respect to the unit load path, and generators in
89 <filename>/run</filename> overwrite those in
90 <filename>/etc</filename>.</para>
91
92 <para>After installing new generators or updating the
93 configuration, <command>systemctl daemon-reload</command> may be
94 executed. This will delete the previous configuration created by
95 generators, re-run all generators, and cause
96 <command>systemd</command> to reload units from disk. See
97 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
98 for more information.
99 </para>
100 </refsect1>
101
102 <refsect1>
103 <title>Output directories</title>
104
105 <para>Generators are invoked with three arguments: paths to directories where
106 generators can place their generated unit files or symlinks. By default those
107 paths are runtime directories that are included in the search path of
108 <command>systemd</command>, but a generator may be called with different paths
109 for debugging purposes.</para>
110
111 <orderedlist>
112 <listitem>
113 <para><parameter>normal-dir</parameter></para>
114 <para>In normal use this is <filename>/run/systemd/generator</filename> in
115 case of the system generators and
116 <filename>$XDG_RUNTIME_DIR/generator</filename> in case of the user
117 generators. Unit files placed in this directory take precedence over vendor
118 unit configuration but not over native user/administrator unit configuration.
119 </para>
120 </listitem>
121
122 <listitem>
123 <para><parameter>early-dir</parameter></para>
124 <para>In normal use this is <filename>/run/systemd/generator.early</filename>
125 in case of the system generators and
126 <filename>$XDG_RUNTIME_DIR/generator.early</filename> in case of the user
127 generators. Unit files placed in this directory override unit files in
128 <filename>/usr</filename>, <filename>/run</filename> and
129 <filename>/etc</filename>. This means that unit files placed in this
130 directory take precedence over all normal configuration, both vendor and
131 user/administrator.</para>
132 </listitem>
133
134 <listitem>
135 <para><parameter>late-dir</parameter></para>
136 <para>In normal use this is <filename>/run/systemd/generator.late</filename>
137 in case of the system generators and
138 <filename>$XDG_RUNTIME_DIR/generator.late</filename> in case of the user
139 generators. This directory may be used to extend the unit file tree without
140 overriding any other unit files. Any native configuration files supplied by
141 the vendor or user/administrator take precedence.</para>
142 </listitem>
143 </orderedlist>
144 </refsect1>
145
146 <refsect1>
147 <title>Notes about writing generators</title>
148
149 <itemizedlist>
150 <listitem>
151 <para>All generators are executed in parallel. That means all executables are
152 started at the very same time and need to be able to cope with this
153 parallelism.
154 </para>
155 </listitem>
156
157 <listitem>
158 <para>Generators are run very early at boot and cannot rely on any external
159 services. They may not talk to any other process. That includes simple things
160 such as logging to
161 <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
162 or <command>systemd</command> itself (this means: no
163 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)!
164 Non-essential file systems like <filename>/var</filename> and
165 <filename>/home</filename> are mounted after generators have run. Generators
166 can however rely on the most basic kernel functionality to be available,
167 including a mounted <filename>/sys</filename>, <filename>/proc</filename>,
168 <filename>/dev</filename>, <filename>/usr</filename>.
169 </para>
170 </listitem>
171
172 <listitem>
173 <para>Units written by generators are removed when the configuration is
174 reloaded. That means the lifetime of the generated units is closely bound to
175 the reload cycles of <command>systemd</command> itself.</para>
176 </listitem>
177
178 <listitem>
179 <para>Generators should only be used to generate unit files and symlinks to
180 them, not any other kind of configuration. Due to the lifecycle logic
181 mentioned above, generators are not a good fit to generate dynamic
182 configuration for other services. If you need to generate dynamic
183 configuration for other services, do so in normal services you order before
184 the service in question.</para>
185 </listitem>
186
187 <listitem>
188 <para>Since
189 <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
190
191 is not available (see above), log messages have to be written to
192 <filename>/dev/kmsg</filename> instead.</para>
193 </listitem>
194
195 <listitem>
196 <para>It is a good idea to use the <varname>SourcePath=</varname> directive
197 in generated unit files to specify the source configuration file you are
198 generating the unit from. This makes things more easily understood by the
199 user and also has the benefit that systemd can warn the user about
200 configuration files that changed on disk but have not been read yet by
201 systemd.</para>
202 </listitem>
203
204 <listitem>
205 <para>Generators may write out dynamic unit files or just hook unit files
206 into other units with the usual <filename>.wants/</filename> or
207 <filename>.requires/</filename> symlinks. Often, it is nicer to simply
208 instantiate a template unit file from <filename>/usr</filename> with a
209 generator instead of writing out entirely dynamic unit files. Of course, this
210 works only if a single parameter is to be used.</para>
211 </listitem>
212
213 <listitem>
214 <para>If you are careful, you can implement generators in shell scripts. We
215 do recommend C code however, since generators are executed synchronously and
216 hence delay the entire boot if they are slow.</para>
217 </listitem>
218
219 <listitem>
220 <para>Regarding overriding semantics: there are two rules we try to follow
221 when thinking about the overriding semantics:</para>
222
223 <orderedlist numeration="lowerroman">
224 <listitem>
225 <para>User configuration should override vendor configuration. This
226 (mostly) means that stuff from <filename>/etc</filename> should override
227 stuff from <filename>/usr</filename>.</para>
228 </listitem>
229
230 <listitem>
231 <para>Native configuration should override non-native configuration. This
232 (mostly) means that stuff you generate should never override native unit
233 files for the same purpose.</para>
234 </listitem>
235 </orderedlist>
236
237 <para>Of these two rules the first rule is probably the more important one
238 and breaks the second one sometimes. Hence, when deciding whether to use
239 argv[1], argv[2], or argv[3], your default choice should probably be
240 argv[1].</para>
241 </listitem>
242
243 <listitem>
244 <para>Instead of heading off now and writing all kind of generators for
245 legacy configuration file formats, please think twice! It is often a better
246 idea to just deprecate old stuff instead of keeping it artificially alive.
247 </para>
248 </listitem>
249 </itemizedlist>
250 </refsect1>
251
252 <refsect1>
253 <title>Examples</title>
254 <example>
255 <title>systemd-fstab-generator</title>
256
257 <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
258 converts <filename>/etc/fstab</filename> into native mount units. It uses
259 argv[1] as location to place the generated unit files in order to allow the
260 user to override <filename>/etc/fstab</filename> with their own native unit
261 files, but also to ensure that <filename>/etc/fstab</filename> overrides any
262 vendor default from <filename>/usr</filename>.</para>
263
264 <para>After editing <filename>/etc/fstab</filename>, the user should invoke
265 <command>systemctl daemon-reload</command>. This will re-run all generators and
266 cause <command>systemd</command> to reload units from disk. To actually mount
267 new directories added to <filename>fstab</filename>, <command>systemctl start
268 <replaceable>/path/to/mountpoint</replaceable></command> or <command>systemctl
269 start local-fs.target</command> may be used.</para>
270 </example>
271
272 <example>
273 <title>systemd-system-update-generator</title>
274
275 <para><citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
276 temporarily redirects <filename>default.target</filename> to
277 <filename>system-update.target</filename>, if a system update is
278 scheduled. Since this needs to override the default user configuration for
279 <filename>default.target</filename>, it uses argv[2]. For details about this
280 logic, see
281 <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
282 </para>
283 </example>
284
285 <example>
286 <title>Debugging a generator</title>
287
288 <programlisting>dir=$(mktemp -d)
289 SYSTEMD_LOG_LEVEL=debug &systemgeneratordir;/systemd-fstab-generator \
290 "$dir" "$dir" "$dir"
291 find $dir</programlisting>
292 </example>
293 </refsect1>
294
295 <refsect1>
296 <title>See also</title>
297
298 <para>
299 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
300 <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
301 <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
302 <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
303 <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
304 <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
305 <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
306 <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
307 <citerefentry><refentrytitle>systemd-rc-local-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
308 <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
309 <citerefentry><refentrytitle>systemd-sysv-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
310 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
311 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
312 <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
313 </para>
314 </refsect1>
315 </refentry>