1ENVIRONMENT.D(5) environment.d ENVIRONMENT.D(5)
2
6 environment.d - Definition of user service environment
7
9 ~/.config/environment.d/*.conf
10 /etc/environment.d/*.conf
12 /run/environment.d/*.conf
14 /usr/lib/environment.d/*.conf
16 /etc/environment
18
20 Configuration files in the environment.d/ directories contain lists of
21 environment variable assignments passed to services started by the
22 systemd user instance. systemd-environment-d-generator(8) parses them
23 and updates the environment exported by the systemd user instance. See
24 below for an discussion of which processes inherit those variables.
25 It is recommended to use numerical prefixes for file names to simplify
27 ordering.
28 For backwards compatibility, a symlink to /etc/environment is
30 installed, so this file is also parsed.
31
33 Configuration files are read from directories in /etc/, /run/,
34 /usr/local/lib/, and /usr/lib/, in order of precedence, as listed in
35 the SYNOPSIS section above. Files must have the ".conf" extension.
36 Files in /etc/ override files with the same name in /run/,
37 /usr/local/lib/, and /usr/lib/. Files in /run/ override files with the
38 same name under /usr/.
39 All configuration files are sorted by their filename in lexicographic
41 order, regardless of which of the directories they reside in. If
42 multiple files specify the same option, the entry in the file with the
43 lexicographically latest name will take precedence. Thus, the
44 configuration in a certain file may either be replaced completely (by
45 placing a file with the same name in a directory with higher priority),
46 or individual settings might be changed (by specifying additional
47 settings in a file with a different name that is ordered later).
48 Packages should install their configuration files in /usr/lib/
50 (distribution packages) or /usr/local/lib/ (local installs). Files in
51 /etc/ are reserved for the local administrator, who may use this logic
52 to override the configuration files installed by vendor packages. It is
53 recommended to prefix all filenames with a two-digit number and a dash,
54 to simplify the ordering of the files.
55 If the administrator wants to disable a configuration file supplied by
57 the vendor, the recommended way is to place a symlink to /dev/null in
58 the configuration directory in /etc/, with the same filename as the
59 vendor configuration file. If the vendor configuration file is included
60 in the initrd image, the image has to be regenerated.
61
63 The configuration files contain a list of "KEY=VALUE" environment
64 variable assignments, separated by newlines. The right hand side of
65 these assignments may reference previously defined environment
66 variables, using the "${OTHER_KEY}" and "$OTHER_KEY" format. It is also
67 possible to use "${FOO:-DEFAULT_VALUE}" to expand in the same way as
68 "${FOO}" unless the expansion would be empty, in which case it expands
69 to DEFAULT_VALUE, and use "${FOO:+ALTERNATE_VALUE}" to expand to
70 ALTERNATE_VALUE as long as "${FOO}" would have expanded to a non-empty
71 value. No other elements of shell syntax are supported.
72 Each KEY must be a valid variable name. Empty lines and lines beginning
74 with the comment character "#" are ignored.
75 Example
77 Example 1. Setup environment to allow access to a program installed in
78 /opt/foo
79 /etc/environment.d/60-foo.conf:
81 FOO_DEBUG=force-software-gl,log-verbose
83 PATH=/opt/foo/bin:$PATH
84 LD_LIBRARY_PATH=/opt/foo/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
85 XDG_DATA_DIRS=/opt/foo/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}
86
89 Environment variables exported by the user service manager (systemd
90 --user instance started in the user@uid.service system service) are
91 passed to any services started by that service manager. In particular,
92 this may include services which run user shells. For example in the
93 GNOME environment, the graphical terminal emulator runs as the
94 gnome-terminal-server.service user unit, which in turn runs the user
95 shell, so that shell will inherit environment variables exported by the
96 user manager. For other instances of the shell, not launched by the
97 user service manager, the environment they inherit is defined by the
98 program that starts them. Hint: in general, systemd.service(5) units
99 contain programs launched by systemd, and systemd.scope(5) units
100 contain programs launched by something else.
101 Note that these files do not affect the environment block of the
103 service manager itself, but exclusively the environment blocks passed
104 to the services it manages. Environment variables set that way thus
105 cannot be used to influence behaviour of the service manager. In order
106 to make changes to the service manager's environment block the
107 environment must be modified before the user's service manager is
108 invoked, for example from the system service manager or via a PAM
109 module.
110 Specifically, for ssh logins, the sshd(8) service builds an environment
112 that is a combination of variables forwarded from the remote system and
113 defined by sshd, see the discussion in ssh(1). A graphical display
114 session will have an analogous mechanism to define the environment.
115 Note that some managers query the systemd user instance for the
116 exported environment and inject this configuration into programs they
117 start, using systemctl show-environment or the underlying D-Bus call.
118
120 systemd(1), systemd-environment-d-generator(8), systemd.environment-
121 generator(7)
122systemd 254 ENVIRONMENT.D(5)