mirror of
https://github.com/systemd/systemd
synced 2024-09-06 16:56:43 +00:00
![Zbigniew Jędrzejewski-Szmek](/assets/img/avatar_default.png)
Since we document /usr/local/lib/systemd/ and other paths for various things,
add notes that this is not supported if /usr/local is a separate partition. In
systemd.unit, I tried to add the footnote in the table where
/usr/local/lib/systemd/ is listed, but that get's rendered as '[sup]a[/sup]'
with a mangled footnote at the bottom of the table :( .
Also, split paragraphs in one place where the subject changes without any
transition.
Follow-up for 02f35b1c90
.
Replaces https://github.com/systemd/systemd/pull/33231.
405 lines
22 KiB
XML
405 lines
22 KiB
XML
<?xml version='1.0'?> <!--*-nxml-*-->
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
<!ENTITY % entities SYSTEM "custom-entities.ent" >
|
|
%entities;
|
|
]>
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
|
|
|
<refentry id="systemd.generator" xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
<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="opt"><replaceable>early-dir</replaceable></arg>
|
|
<arg choice="opt"><replaceable>late-dir</replaceable></arg>
|
|
</cmdsynopsis>
|
|
|
|
<para><simplelist>
|
|
<member><filename>/run/systemd/system-generators/*</filename></member>
|
|
<member><filename>/etc/systemd/system-generators/*</filename></member>
|
|
<member><filename>/usr/local/lib/systemd/system-generators/*</filename></member>
|
|
<member><filename>&SYSTEM_GENERATOR_DIR;/*</filename></member>
|
|
</simplelist></para>
|
|
|
|
<para><simplelist>
|
|
<member><filename>/run/systemd/user-generators/*</filename></member>
|
|
<member><filename>/etc/systemd/user-generators/*</filename></member>
|
|
<member><filename>/usr/local/lib/systemd/user-generators/*</filename></member>
|
|
<member><filename>&USER_GENERATOR_DIR;/*</filename></member>
|
|
</simplelist></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 <xi:include href="standard-conf.xml" xpointer="usr-local-footnote" />.
|
|
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
|
|
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>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v251"/></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>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v251"/></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>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v251"/></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>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v251"/></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>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v251"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>$CREDENTIALS_DIRECTORY</varname></term>
|
|
<term><varname>$ENCRYPTED_CREDENTIALS_DIRECTORY</varname></term>
|
|
|
|
<listitem><para>If set, refers to the directory system credentials have been placed in. Credentials
|
|
passed into the system in plaintext form will be placed in <varname>$CREDENTIALS_DIRECTORY</varname>,
|
|
and those passed in in encrypted form will be placed in
|
|
<varname>$ENCRYPTED_CREDENTIALS_DIRECTORY</varname>. Use the
|
|
<citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
command to automatically decrypt/authenticate credentials passed in, if needed. Specifically, use the
|
|
<command>systemd-creds --system cat</command> command.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION</varname></term>
|
|
|
|
<listitem><para>If the service manager is run in a confidential virtualized environment,
|
|
<varname>$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION</varname> is set to a string that identifies
|
|
the confidential virtualization hardware technology. If no confidential 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 confidential virtualization
|
|
technology identifiers.</para>
|
|
|
|
<xi:include href="version-info.xml" xpointer="v254"/></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><simplelist type="inline">
|
|
<member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-rc-local-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-sysv-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd-xdg-autostart-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
|
|
<member><citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
|
|
</simplelist></para>
|
|
</refsect1>
|
|
</refentry>
|