environment.d
systemd
environment.d
5
environment.d
Definition of user service environment
~/.config/environment.d/*.conf
/etc/environment.d/*.conf
/run/environment.d/*.conf
/usr/local/lib/environment.d/*.conf
/usr/lib/environment.d/*.conf
/etc/environment
Description
Configuration files in the environment.d/ directories contain lists of
environment variable assignments passed to services started by the systemd user instance.
systemd-environment-d-generator8
parses them and updates the environment exported by the systemd user instance. See below for an
discussion of which processes inherit those variables.
It is recommended to use numerical prefixes for file names to simplify ordering.
For backwards compatibility, a symlink to /etc/environment is
installed, so this file is also parsed.
Configuration Format
The configuration files contain a list of
KEY=VALUE environment
variable assignments, separated by newlines. The right hand side of these assignments may
reference previously defined environment variables, using the ${OTHER_KEY}
and $OTHER_KEY format. It is also possible to use
${FOO:-DEFAULT_VALUE}
to expand in the same way as ${FOO} unless the
expansion would be empty, in which case it expands to DEFAULT_VALUE,
and use
${FOO:+ALTERNATE_VALUE}
to expand to ALTERNATE_VALUE as long as
${FOO} would have expanded to a non-empty value.
No other elements of shell syntax are supported.
Each KEY must be a valid variable name. Empty lines
and lines beginning with the comment character # are ignored.
Example
Setup environment to allow access to a program installed in
/opt/foo
/etc/environment.d/60-foo.conf:
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/}
Applicability
Environment variables exported by the user service manager (systemd --user
instance started in the user@uid.service 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
gnome-terminal-server.service 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,
systemd.service5 units
contain programs launched by systemd, and
systemd.scope5 units
contain programs launched by something else.
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.
Specifically, for ssh logins, the
sshd8
service builds an environment that is a combination of variables forwarded from the remote system and
defined by sshd, see the discussion in
ssh1.
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 systemctl show-environment or the underlying D-Bus call.
See Also
systemd1
systemd-environment-d-generator8
systemd.environment-generator7