diff options
Diffstat (limited to 'man/systemd.generator.xml')
| -rw-r--r-- | man/systemd.generator.xml | 318 |
1 files changed, 318 insertions, 0 deletions
diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml new file mode 100644 index 0000000..5007563 --- /dev/null +++ b/man/systemd.generator.xml @@ -0,0 +1,318 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="systemd.generator"> + <refentryinfo> + <title>systemd.generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.generator</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.generator</refname> + <refpurpose>systemd unit generators</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>/path/to/generator</command> + <arg choice="plain"><replaceable>normal-dir</replaceable></arg> + <arg choice="plain"><replaceable>early-dir</replaceable></arg> + <arg choice="plain"><replaceable>late-dir</replaceable></arg> + </cmdsynopsis> + + <para> + <literallayout><filename>/run/systemd/system-generators/*</filename> +<filename>/etc/systemd/system-generators/*</filename> +<filename>/usr/local/lib/systemd/system-generators/*</filename> +<filename>&systemgeneratordir;/*</filename></literallayout> + </para> + + <para> + <literallayout><filename>/run/systemd/user-generators/*</filename> +<filename>/etc/systemd/user-generators/*</filename> +<filename>/usr/local/lib/systemd/user-generators/*</filename> +<filename>&usergeneratordir;/*</filename></literallayout> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para>Generators are small executables that live in + <filename>&systemgeneratordir;/</filename> and other directories listed above. + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + will execute those binaries very early at bootup and at configuration reload time + — before unit files are loaded. Their main purpose is to convert configuration + that is not native into dynamically generated unit files.</para> + + <para>Each generator is called with three directory paths that are to be used for + generator output. In these three directories, generators may dynamically generate + unit files (regular ones, instances, as well as templates), unit file + <filename>.d/</filename> drop-ins, and create symbolic links to unit files to add + additional dependencies, create aliases, or instantiate existing templates. Those + directories are included in the unit load path of + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + allowing generated configuration to extend or override existing + definitions.</para> + + <para>Directory paths for generator output differ by priority: + <filename>…/generator.early</filename> has priority higher than the admin + configuration in <filename>/etc</filename>, while + <filename>…/generator</filename> has lower priority than + <filename>/etc</filename> but higher than vendor configuration in + <filename>/usr</filename>, and <filename>…/generator.late</filename> has priority + lower than all other configuration. See the next section and the discussion of + unit load paths and unit overriding in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>Generators are loaded from a set of paths determined during + compilation, as listed above. System and user generators are loaded + from directories with names ending in + <filename>system-generators/</filename> and + <filename>user-generators/</filename>, respectively. Generators + found in directories listed earlier override the ones with the + same name in directories lower in the list. A symlink to + <filename>/dev/null</filename> or an empty file can be used to + mask a generator, thereby preventing it from running. Please note + that the order of the two directories with the highest priority is + reversed with respect to the unit load path, and generators in + <filename>/run</filename> overwrite those in + <filename>/etc</filename>.</para> + + <para>After installing new generators or updating the + configuration, <command>systemctl daemon-reload</command> may be + executed. This will delete the previous configuration created by + generators, re-run all generators, and cause + <command>systemd</command> to reload units from disk. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for more information. + </para> + </refsect1> + + <refsect1> + <title>Output directories</title> + + <para>Generators are invoked with three arguments: paths to directories where + generators can place their generated unit files or symlinks. By default those + paths are runtime directories that are included in the search path of + <command>systemd</command>, but a generator may be called with different paths + for debugging purposes.</para> + + <orderedlist> + <listitem> + <para><parameter>normal-dir</parameter></para> + <para>In normal use this is <filename>/run/systemd/generator</filename> in + case of the system generators and + <filename>$XDG_RUNTIME_DIR/generator</filename> in case of the user + generators. Unit files placed in this directory take precedence over vendor + unit configuration but not over native user/administrator unit configuration. + </para> + </listitem> + + <listitem> + <para><parameter>early-dir</parameter></para> + <para>In normal use this is <filename>/run/systemd/generator.early</filename> + in case of the system generators and + <filename>$XDG_RUNTIME_DIR/generator.early</filename> in case of the user + generators. Unit files placed in this directory override unit files in + <filename>/usr</filename>, <filename>/run</filename> and + <filename>/etc</filename>. This means that unit files placed in this + directory take precedence over all normal configuration, both vendor and + user/administrator.</para> + </listitem> + + <listitem> + <para><parameter>late-dir</parameter></para> + <para>In normal use this is <filename>/run/systemd/generator.late</filename> + in case of the system generators and + <filename>$XDG_RUNTIME_DIR/generator.late</filename> in case of the user + generators. This directory may be used to extend the unit file tree without + overriding any other unit files. Any native configuration files supplied by + 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> + + <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>Examples</title> + <example> + <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 their 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> + <title>systemd-system-update-generator</title> + + <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 + <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </example> + + <example> + <title>Debugging a generator</title> + + <programlisting>dir=$(mktemp -d) +SYSTEMD_LOG_LEVEL=debug &systemgeneratordir;/systemd-fstab-generator \ + "$dir" "$dir" "$dir" +find $dir</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-rc-local-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-sysv-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> |