1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
'\" t
.TH "ENVIRONMENT\&.D" "5" "" "systemd 256~rc3" "environment.d"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
environment.d \- Definition of user service environment
.SH "SYNOPSIS"
.PP
.RS 4
~/\&.config/environment\&.d/*\&.conf
.RE
.RS 4
/etc/environment\&.d/*\&.conf
.RE
.RS 4
/run/environment\&.d/*\&.conf
.RE
.RS 4
/usr/lib/environment\&.d/*\&.conf
.RE
.RS 4
/etc/environment
.RE
.SH "DESCRIPTION"
.PP
Configuration files in the
environment\&.d/
directories contain lists of environment variable assignments passed to services started by the systemd user instance\&.
\fBsystemd-environment-d-generator\fR(8)
parses them and updates the environment exported by the systemd user instance\&. See below for an discussion of which processes inherit those variables\&.
.PP
It is recommended to use numerical prefixes for file names to simplify ordering\&.
.PP
For backwards compatibility, a symlink to
/etc/environment
is installed, so this file is also parsed\&.
.SH "CONFIGURATION DIRECTORIES AND PRECEDENCE"
.PP
Configuration files are read from directories in
/etc/,
/run/,
/usr/local/lib/, and
/usr/lib/, in order of precedence, as listed in the SYNOPSIS section above\&. Files must have the
"\&.conf"
extension\&. Files in
/etc/
override files with the same name in
/run/,
/usr/local/lib/, and
/usr/lib/\&. Files in
/run/
override files with the same name under
/usr/\&.
.PP
All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in\&. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence\&. Thus, the configuration in a certain file may either be replaced completely (by placing a file with the same name in a directory with higher priority), or individual settings might be changed (by specifying additional settings in a file with a different name that is ordered later)\&.
.PP
Packages should install their configuration files in
/usr/lib/
(distribution packages) or
/usr/local/lib/
(local installs)\&. Files in
/etc/
are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages\&. It is recommended to prefix all filenames with a two\-digit number and a dash, to simplify the ordering of the files\&. It is recommended to use the range 10\-40 for configuration files in
/usr/
and the range 60\-90 for configuration files in
/etc/
and
/run/, to make sure that local and transient configuration files will always take priority over configuration files shipped by the OS vendor\&.
.PP
If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to
/dev/null
in the configuration directory in
/etc/, with the same filename as the vendor configuration file\&. If the vendor configuration file is included in the initrd image, the image has to be regenerated\&.
.SH "CONFIGURATION FORMAT"
.PP
The configuration files contain a list of
"\fIKEY\fR=\fIVALUE\fR"
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
"${\fIFOO\fR:\-\fIDEFAULT_VALUE\fR}"
to expand in the same way as
"${\fIFOO\fR}"
unless the expansion would be empty, in which case it expands to
\fIDEFAULT_VALUE\fR, and use
"${\fIFOO\fR:+\fIALTERNATE_VALUE\fR}"
to expand to
\fIALTERNATE_VALUE\fR
as long as
"${\fIFOO\fR}"
would have expanded to a non\-empty value\&. No other elements of shell syntax are supported\&.
.PP
Each
\fIKEY\fR
must be a valid variable name\&. Empty lines and lines beginning with the comment character
"#"
are ignored\&.
.SS "Example"
.PP
\fBExample\ \&1.\ \&Setup environment to allow access to a program installed in /opt/foo\fR
.PP
/etc/environment\&.d/60\-foo\&.conf:
.sp
.if n \{\
.RS 4
.\}
.nf
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/}
.fi
.if n \{\
.RE
.\}
.SH "APPLICABILITY"
.PP
Environment variables exported by the user service manager (\fBsystemd \-\-user\fR
instance started in the
user@\fIuid\fR\&.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,
\fBsystemd.service\fR(5)
units contain programs launched by systemd, and
\fBsystemd.scope\fR(5)
units contain programs launched by something else\&.
.PP
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\*(Aqs environment block the environment must be modified before the user\*(Aqs service manager is invoked, for example from the system service manager or via a PAM module\&.
.PP
Specifically, for ssh logins, the
\fBsshd\fR(8)
service builds an environment that is a combination of variables forwarded from the remote system and defined by
\fBsshd\fR, see the discussion in
\fBssh\fR(1)\&. 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
\fBsystemctl show\-environment\fR
or the underlying D\-Bus call\&.
.SH "SEE ALSO"
.PP
\fBsystemd\fR(1), \fBsystemd-environment-d-generator\fR(8), \fBsystemd.environment-generator\fR(7)
|
