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