<!--
SPDX-License-Identifier: LGPL-2.1+
- This file is part of systemd.
-
Copyright 2015 Zbigniew Jędrzejewski-Szmek
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-
- systemd is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public License
- along with systemd; If not, see <http://www.gnu.org/licenses/>.
-->
<refentry id="systemd.generator">
the vendor or user/administrator take precedence.</para>
</listitem>
</orderedlist>
+ </refsect1>
+
+ <refsect1>
+ <title>Notes about writing generators</title>
+
+ <itemizedlist>
+ <listitem>
+ <para>All generators are executed in parallel. That means all executables are
+ started at the very same time and need to be able to cope with this
+ parallelism.
+ </para>
+ </listitem>
- <refsect2>
- <title>Notes</title>
-
- <itemizedlist>
- <listitem>
- <para>
- All generators are executed in parallel. That means all
- executables are started at the very same time and need to
- be able to cope with this parallelism.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Generators are run very early at boot and cannot rely on
- any external services. They may not talk to any other
- process. That includes simple things such as logging to
- <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
- or <command>systemd</command> itself (this means: no
- <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)!
- Non-essential file systems like
- <filename>/var</filename> and <filename>/home</filename>
- are mounted after generators have run. Generators
- can however rely on the most basic kernel functionality to be
- available, including a mounted <filename>/sys</filename>,
- <filename>/proc</filename>, <filename>/dev</filename>,
- <filename>/usr</filename>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Units written by generators are removed when the configuration
- is reloaded. That means the lifetime of the generated
- units is closely bound to the reload cycles of
- <command>systemd</command> itself.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Generators should only be used to generate unit files and symlinks to them, not any other kind of
- configuration. Due to the lifecycle logic mentioned above, generators are not a good fit to generate
- dynamic configuration for other services. If you need to generate dynamic configuration for other services,
- do so in normal services you order before the service in question.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Since
- <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- is not available (see above), log messages have to be
- written to <filename>/dev/kmsg</filename> instead.
- </para>
- </listitem>
-
- <listitem>
- <para>
- It is a good idea to use the
- <varname>SourcePath=</varname> directive in generated unit
- files to specify the source configuration file you are
- generating the unit from. This makes things more easily
- understood by the user and also has the benefit that
- systemd can warn the user about configuration files that
- changed on disk but have not been read yet by systemd.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Generators may write out dynamic unit files or just hook
- unit files into other units with the usual
- <filename>.wants/</filename> or
- <filename>.requires/</filename> symlinks. Often, it is
- nicer to simply instantiate a template unit file from
- <filename>/usr</filename> with a generator instead of
- writing out entirely dynamic unit files. Of course, this
- works only if a single parameter is to be used.
- </para>
- </listitem>
-
- <listitem>
- <para>
- If you are careful, you can implement generators in shell
- scripts. We do recommend C code however, since generators
- are executed synchronously and hence delay the
- entire boot if they are slow.
- </para>
- </listitem>
-
- <listitem>
- <para>Regarding overriding semantics: there are two rules we
- try to follow when thinking about the overriding semantics:
- </para>
-
- <orderedlist numeration="lowerroman">
- <listitem>
- <para>User configuration should override vendor
- configuration. This (mostly) means that stuff from
- <filename>/etc</filename> should override stuff from
- <filename>/usr</filename>.</para>
- </listitem>
-
- <listitem>
- <para>Native configuration should override non-native
- configuration. This (mostly) means that stuff you
- generate should never override native unit files for the
- same purpose.</para>
- </listitem>
- </orderedlist>
-
- <para>Of these two rules the first rule is probably the more
- important one and breaks the second one sometimes. Hence,
- when deciding whether to use argv[1], argv[2], or argv[3],
- your default choice should probably be argv[1].</para>
- </listitem>
-
- <listitem>
- <para>
- Instead of heading off now and writing all kind of
- generators for legacy configuration file formats, please
- think twice! It is often a better idea to just deprecate
- old stuff instead of keeping it artificially alive.
- </para>
- </listitem>
- </itemizedlist>
- </refsect2>
+ <listitem>
+ <para>Generators are run very early at boot and cannot rely on any external
+ services. They may not talk to any other process. That includes simple things
+ such as logging to
+ <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+ or <command>systemd</command> itself (this means: no
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)!
+ Non-essential file systems like <filename>/var</filename> and
+ <filename>/home</filename> are mounted after generators have run. Generators
+ can however rely on the most basic kernel functionality to be available,
+ including a mounted <filename>/sys</filename>, <filename>/proc</filename>,
+ <filename>/dev</filename>, <filename>/usr</filename>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Units written by generators are removed when the configuration is
+ reloaded. That means the lifetime of the generated units is closely bound to
+ the reload cycles of <command>systemd</command> itself.</para>
+ </listitem>
+
+ <listitem>
+ <para>Generators should only be used to generate unit files and symlinks to
+ them, not any other kind of configuration. Due to the lifecycle logic
+ mentioned above, generators are not a good fit to generate dynamic
+ configuration for other services. If you need to generate dynamic
+ configuration for other services, do so in normal services you order before
+ the service in question.</para>
+ </listitem>
+
+ <listitem>
+ <para>Since
+ <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+
+ is not available (see above), log messages have to be written to
+ <filename>/dev/kmsg</filename> instead.</para>
+ </listitem>
+
+ <listitem>
+ <para>It is a good idea to use the <varname>SourcePath=</varname> directive
+ in generated unit files to specify the source configuration file you are
+ generating the unit from. This makes things more easily understood by the
+ user and also has the benefit that systemd can warn the user about
+ configuration files that changed on disk but have not been read yet by
+ systemd.</para>
+ </listitem>
+
+ <listitem>
+ <para>Generators may write out dynamic unit files or just hook unit files
+ into other units with the usual <filename>.wants/</filename> or
+ <filename>.requires/</filename> symlinks. Often, it is nicer to simply
+ instantiate a template unit file from <filename>/usr</filename> with a
+ generator instead of writing out entirely dynamic unit files. Of course, this
+ works only if a single parameter is to be used.</para>
+ </listitem>
+
+ <listitem>
+ <para>If you are careful, you can implement generators in shell scripts. We
+ do recommend C code however, since generators are executed synchronously and
+ hence delay the entire boot if they are slow.</para>
+ </listitem>
+
+ <listitem>
+ <para>Regarding overriding semantics: there are two rules we try to follow
+ when thinking about the overriding semantics:</para>
+
+ <orderedlist numeration="lowerroman">
+ <listitem>
+ <para>User configuration should override vendor configuration. This
+ (mostly) means that stuff from <filename>/etc</filename> should override
+ stuff from <filename>/usr</filename>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Native configuration should override non-native configuration. This
+ (mostly) means that stuff you generate should never override native unit
+ files for the same purpose.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Of these two rules the first rule is probably the more important one
+ and breaks the second one sometimes. Hence, when deciding whether to use
+ argv[1], argv[2], or argv[3], your default choice should probably be
+ argv[1].</para>
+ </listitem>
+
+ <listitem>
+ <para>Instead of heading off now and writing all kind of generators for
+ legacy configuration file formats, please think twice! It is often a better
+ idea to just deprecate old stuff instead of keeping it artificially alive.
+ </para>
+ </listitem>
+ </itemizedlist>
</refsect1>
<refsect1>
<title>systemd-fstab-generator</title>
<para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- converts <filename>/etc/fstab</filename> into native mount
- units. It uses argv[1] as location to place the generated unit
- files in order to allow the user to override
- <filename>/etc/fstab</filename> with her own native unit files,
- but also to ensure that <filename>/etc/fstab</filename>
- overrides any vendor default from <filename>/usr</filename>.
- </para>
-
- <para>After editing <filename>/etc/fstab</filename>, the user
- should invoke <command>systemctl daemon-reload</command>. This
- will re-run all generators and cause <command>systemd</command>
- to reload units from disk. To actually mount new directories
- added to <filename>fstab</filename>, <command>systemctl start
- <replaceable>/path/to/mountpoint</replaceable></command> or
- <command>systemctl start local-fs.target</command> may be used.
- </para>
+ converts <filename>/etc/fstab</filename> into native mount units. It uses
+ argv[1] as location to place the generated unit files in order to allow the
+ user to override <filename>/etc/fstab</filename> with her own native unit
+ files, but also to ensure that <filename>/etc/fstab</filename> overrides any
+ vendor default from <filename>/usr</filename>.</para>
+
+ <para>After editing <filename>/etc/fstab</filename>, the user should invoke
+ <command>systemctl daemon-reload</command>. This will re-run all generators and
+ cause <command>systemd</command> to reload units from disk. To actually mount
+ new directories added to <filename>fstab</filename>, <command>systemctl start
+ <replaceable>/path/to/mountpoint</replaceable></command> or <command>systemctl
+ start local-fs.target</command> may be used.</para>
</example>
<example>
<para><citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
temporarily redirects <filename>default.target</filename> to
<filename>system-update.target</filename>, if a system update is
- scheduled. Since this needs to override the default user
- configuration for <filename>default.target</filename>, it uses
- argv[2]. For details about this logic, see
+ scheduled. Since this needs to override the default user configuration for
+ <filename>default.target</filename>, it uses argv[2]. For details about this
+ logic, see
<citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
</example>
projects / thirdparty / systemd.git / blobdiff