| <?xml version='1.0'?> <!--*-nxml-*--> |
| <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//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-or-later --> |
| |
| <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 index='false'>/path/to/generator</command> |
| <arg choice="plain"><replaceable>normal-dir</replaceable></arg> |
| <arg choice="option"><replaceable>early-dir</replaceable></arg> |
| <arg choice="option"><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>&SYSTEM_GENERATOR_DIR;/*</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>&USER_GENERATOR_DIR;/*</filename></literallayout> |
| </para> |
| </refsynopsisdiv> |
| |
| <refsect1> |
| <title>Description</title> |
| <para>Generators are small executables placed in <filename>&SYSTEM_GENERATOR_DIR;/</filename> and other |
| directories listed above. |
| <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will execute |
| these binaries very early at bootup and at configuration reload time — before unit files are |
| loaded. Their main purpose is to convert configuration and execution context parameters that are not |
| native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins, so |
| that they can extend the unit file hierarchy the service manager subsequently loads and operates |
| on.</para> |
| |
| <para><command>systemd</command> will call each generator 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, allowing generated configuration to extend or |
| override existing definitions. For tests, generators may be called with just one argument; the generator |
| should assume that all three paths are the same in that case.</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. If only one argument is provided, the generator should use the same directory as the |
| the three output paths.</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/systemd/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/systemd/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/systemd/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> |
| |
| <para>Note: generators <emphasis>must not</emphasis> write to other locations or otherwise make changes |
| to system state. Generator output is supposed to last only until the next |
| <command>daemon-reload</command> or <command>daemon-reexec</command>; if the generator is replaced |
| or masked, its effects should vanish.</para> |
| </refsect1> |
| |
| <refsect1> |
| <title>Environment</title> |
| |
| <para>The service manager sets a number of environment variables when invoking generator |
| executables. They carry information about the execution context of the generator, in order to simplify |
| conditionalizing generators to specific environments. The following environment variables are set:</para> |
| |
| <variablelist class='environment-variables'> |
| <varlistentry> |
| <term><varname>$SYSTEMD_SCOPE</varname></term> |
| |
| <listitem><para>If the generator is invoked from the system service manager this variable is set to |
| <literal>system</literal>; if invoked from the per-user service manager it is set to |
| <literal>user</literal>.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>$SYSTEMD_IN_INITRD</varname></term> |
| |
| <listitem><para>If the generator is run as part of an initrd this is set to <literal>1</literal>. If |
| it is run from the regular host (i.e. after the transition from initrd to host) it is set to |
| <literal>0</literal>. This environment variable is only set for system generators.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>$SYSTEMD_FIRST_BOOT</varname></term> |
| |
| <listitem><para>If this boot-up cycle is considered a "first boot", this is set to |
| <literal>1</literal>; if it is a subsequent, regular boot it is set to <literal>0</literal>. For |
| details see the documentation of <varname>ConditionFirstBoot=</varname> in |
| <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This |
| environment variable is only set for system generators.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>$SYSTEMD_VIRTUALIZATION</varname></term> |
| |
| <listitem><para>If the service manager is run in a virtualized environment, |
| <varname>$SYSTEMD_VIRTUALIZATION</varname> is set to a pair of strings, separated by a colon. The |
| first string is either <literal>vm</literal> or <literal>container</literal>, categorizing the type |
| of virtualization. The second string identifies the implementation of the virtualization |
| technology. If no virtualization is detected this variable will not be set. This data is identical to |
| what |
| <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry> |
| detects and reports, and uses the same vocabulary of virtualization implementation |
| identifiers.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>$SYSTEMD_ARCHITECTURE</varname></term> |
| |
| <listitem><para>This variable is set to a short identifier of the reported architecture of the |
| system. For details about defined values, see documentation of |
| <varname>ConditionArchitecture=</varname> in |
| <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> |
| </varlistentry> |
| </variablelist> |
| </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, as well as mounted <filename>/sys/</filename>, <filename>/proc/</filename>, |
| <filename>/dev/</filename>, <filename>/usr/</filename> and <filename>/run/</filename> file systems. |
| </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, <filename>.d/*.conf</filename> drop-ins |
| for them and symlinks to them, not any other kind of non-unit related 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> |
| |
| <para>Note that using the <varname>StandardInputData=</varname>/<varname>StandardInputText=</varname> |
| settings of service unit files (see |
| <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>), it |
| is possible to make arbitrary input data (including daemon-specific configuration) part of the unit |
| definitions, which often might be sufficient to embed data or configuration for other programs into |
| unit files in a native fashion.</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>The generator should always include its own name in a comment at the top of the generated file, |
| so that the user can easily figure out which component created or amended a particular unit.</para> |
| |
| <para>The <varname>SourcePath=</varname> directive should be used in generated files to specify the |
| source configuration file they are generated 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. The <varname>SourcePath=</varname> value does not have |
| to be a file in a physical filesystem. For example, in the common case of the generator looking at |
| the kernel command line, <option>SourcePath=/proc/cmdline</option> should be used.</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 &SYSTEM_GENERATOR_DIR;/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-xdg-autostart-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> |