mirror of
https://github.com/systemd/systemd.git
synced 2025-01-11 09:18:07 +03:00
73e97bb064
With <para><filename>…</filename></para>, we get a separate "paragraph" for each line, i.e. entries separated by empty lines. This uses up a lot of space and was only done because docbook makes it hard to insert a newline. In some other places, <literallayout> was used, but then we cannot indent the source text (because the whitespace would end up in the final page). We can get the desired result with <simplelist>. With <simplelist> the items are indented in roff output, but not in html output. In some places this looks better then no indentation, and in others it would probably be better to have no indent. But this is a minor issue and we cannot control that. (I didn't convert all spots. There's a bunch of other man pages which have two lines, e.g. an executable and service file, and it doesn't matter there so much.)
136 lines
6.6 KiB
XML
136 lines
6.6 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.2/docbookx.dtd">
|
|
<!--
|
|
SPDX-License-Identifier: LGPL-2.1-or-later
|
|
|
|
Copyright © 2016 Red Hat, Inc.
|
|
-->
|
|
<refentry id="environment.d" conditional='ENABLE_ENVIRONMENT_D'
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<refentryinfo>
|
|
<title>environment.d</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>environment.d</refentrytitle>
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>environment.d</refname>
|
|
<refpurpose>Definition of user service environment</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<para><simplelist>
|
|
<member><filename>~/.config/environment.d/*.conf</filename></member>
|
|
<member><filename>/etc/environment.d/*.conf</filename></member>
|
|
<member><filename>/run/environment.d/*.conf</filename></member>
|
|
<member><filename>/usr/lib/environment.d/*.conf</filename></member>
|
|
<member><filename>/etc/environment</filename></member>
|
|
</simplelist></para>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>Configuration files in the <filename>environment.d/</filename> directories contain lists of
|
|
environment variable assignments passed to services started by the systemd user instance.
|
|
<citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
parses them and updates the environment exported by the systemd user instance. See below for an
|
|
discussion of which processes inherit those variables.</para>
|
|
|
|
<para>It is recommended to use numerical prefixes for file names to simplify ordering.</para>
|
|
|
|
<para>For backwards compatibility, a symlink to <filename>/etc/environment</filename> is
|
|
installed, so this file is also parsed.</para>
|
|
</refsect1>
|
|
|
|
<xi:include href="standard-conf.xml" xpointer="confd" />
|
|
|
|
<refsect1>
|
|
<title>Configuration Format</title>
|
|
|
|
<para>The configuration files contain a list of
|
|
<literal><replaceable>KEY</replaceable>=<replaceable>VALUE</replaceable></literal> environment
|
|
variable assignments, separated by newlines. The right hand side of these assignments may
|
|
reference previously defined environment variables, using the <literal>${OTHER_KEY}</literal>
|
|
and <literal>$OTHER_KEY</literal> format. It is also possible to use
|
|
<literal>${<replaceable>FOO</replaceable>:-<replaceable>DEFAULT_VALUE</replaceable>}</literal>
|
|
to expand in the same way as <literal>${<replaceable>FOO</replaceable>}</literal> unless the
|
|
expansion would be empty, in which case it expands to <replaceable>DEFAULT_VALUE</replaceable>,
|
|
and use
|
|
<literal>${<replaceable>FOO</replaceable>:+<replaceable>ALTERNATE_VALUE</replaceable>}</literal>
|
|
to expand to <replaceable>ALTERNATE_VALUE</replaceable> as long as
|
|
<literal>${<replaceable>FOO</replaceable>}</literal> would have expanded to a non-empty value.
|
|
No other elements of shell syntax are supported.</para>
|
|
|
|
<para>Each <replaceable>KEY</replaceable> must be a valid variable name. Empty lines
|
|
and lines beginning with the comment character <literal>#</literal> are ignored.</para>
|
|
|
|
<refsect2>
|
|
<title>Example</title>
|
|
<example>
|
|
<title>Setup environment to allow access to a program installed in
|
|
<filename index="false">/opt/foo</filename></title>
|
|
|
|
<para><filename index="false">/etc/environment.d/60-foo.conf</filename>:
|
|
</para>
|
|
<programlisting>
|
|
FOO_DEBUG=force-software-gl,log-verbose
|
|
PATH=/opt/foo/bin:$PATH
|
|
LD_LIBRARY_PATH=/opt/foo/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
|
|
XDG_DATA_DIRS=/opt/foo/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}
|
|
</programlisting>
|
|
</example>
|
|
</refsect2>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Applicability</title>
|
|
|
|
<para>Environment variables exported by the user service manager (<command>systemd --user</command>
|
|
instance started in the <filename>user@<replaceable>uid</replaceable>.service</filename> system service)
|
|
are passed to any services started by that service manager. In particular, this may include services
|
|
which run user shells. For example in the GNOME environment, the graphical terminal emulator runs as the
|
|
<filename>gnome-terminal-server.service</filename> user unit, which in turn runs the user shell, so that
|
|
shell will inherit environment variables exported by the user manager. For other instances of the shell,
|
|
not launched by the user service manager, the environment they inherit is defined by the program that
|
|
starts them. Hint: in general,
|
|
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> units
|
|
contain programs launched by systemd, and
|
|
<citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry> units
|
|
contain programs launched by something else.</para>
|
|
|
|
<para>Note that these files do not affect the environment block of the service manager itself, but
|
|
exclusively the environment blocks passed to the services it manages. Environment variables set that way
|
|
thus cannot be used to influence behaviour of the service manager. In order to make changes to the
|
|
service manager's environment block the environment must be modified before the user's service manager is
|
|
invoked, for example from the system service manager or via a PAM module.</para>
|
|
|
|
<para>Specifically, for ssh logins, the
|
|
<citerefentry project='die-net'><refentrytitle>sshd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
service builds an environment that is a combination of variables forwarded from the remote system and
|
|
defined by <command>sshd</command>, see the discussion in
|
|
<citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
|
A graphical display session will have an analogous mechanism to define the environment. Note that some
|
|
managers query the systemd user instance for the exported environment and inject this configuration into
|
|
programs they start, using <command>systemctl show-environment</command> or the underlying D-Bus call.
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|