systemd/man/systemd.environment-generator.xml
Zbigniew Jędrzejewski-Szmek 11a1589223 tree-wide: drop license boilerplate
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.

I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
2018-04-06 18:58:55 +02:00

151 lines
5.9 KiB
XML

<?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+
This file is part of systemd.
Copyright 2017 Zbigniew Jędrzejewski-Szmek
-->
<refentry id="systemd.environment-generator" conditional='ENABLE_ENVIRONMENT_D'
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>systemd.environment-generator</title>
<productname>systemd</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Zbigniew</firstname>
<surname>Jędrzejewski-Szmek</surname>
<email>zbyszek@in.waw.pl</email>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>systemd.environment-generator</refentrytitle>
<manvolnum>7</manvolnum>
</refmeta>
<refnamediv>
<refname>systemd.environment-generator</refname>
<refpurpose>systemd environment file generators</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>&systemenvgeneratordir;/some-generator</command>
</cmdsynopsis>
<cmdsynopsis>
<command>&userenvgeneratordir;/some-generator</command>
</cmdsynopsis>
<para>
<literallayout><filename>/run/systemd/system-environment-generators/*</filename>
<filename>/etc/systemd/system-environment-generators/*</filename>
<filename>/usr/local/lib/systemd/system-environment-generators/*</filename>
<filename>&systemenvgeneratordir;/*</filename></literallayout>
</para>
<para>
<literallayout><filename>/run/systemd/user-environment-generators/*</filename>
<filename>/etc/systemd/user-environment-generators/*</filename>
<filename>/usr/local/lib/systemd/user-environment-generators/*</filename>
<filename>&userenvgeneratordir;/*</filename></literallayout>
</para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Generators are small executables that live in
<filename>&systemenvgeneratordir;/</filename> and other directories listed above.
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will
execute those binaries very early at the startup of each manager and at configuration
reload time, before running the generators described in
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
and before starting any units. Environment generators can override the environment that the
manager exports to services and other processes.</para>
<para>Generators are loaded from a set of paths determined during compilation, as listed
above. System and user environment generators are loaded from directories with names ending in
<filename>system-environment-generators/</filename> and
<filename>user-environment-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 re-run all generators, updating environment
configuration. It will be used for any services that are started subsequently.</para>
<para>Environment file generators are executed similarly to unit file generators described
in
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
with the following differences:</para>
<itemizedlist>
<listitem>
<para>Generators are executed sequentially in the alphanumerical order of the final
component of their name. The output of each generator output is immediately parsed and used
to update the environment for generators that run after that. Thus, later generators can use
and/or modify the output of earlier generators.</para>
</listitem>
<listitem>
<para>Generators are run by every manager instance, their output can be different for each
user.</para>
</listitem>
</itemizedlist>
<para>It is recommended to use numerical prefixes for generator names to simplify ordering.</para>
</refsect1>
<refsect1>
<title>Examples</title>
<example>
<title>A simple generator that extends an environment variable if a directory exists in the file system</title>
<programlisting># 50-xdg-data-dirs.sh
<xi:include href="50-xdg-data-dirs.sh" parse="text" /></programlisting>
</example>
<example>
<title>A more complicated generator which reads existing configuration and mutates one variable</title>
<programlisting># 90-rearrange-path.py
<xi:include href="90-rearrange-path.py" parse="text" /></programlisting>
</example>
<example>
<title>Debugging a generator</title>
<programlisting>SYSTEMD_LOG_LEVEL=debug VAR_A=something VAR_B="something else" \
&systemenvgeneratordir;/path-to-generator
</programlisting>
</example>
</refsect1>
<refsect1>
<title>See also</title>
<para>
<citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>