ENVIRONMENT.D(5)

🦋 ENVIRONMENT.D 🦋

okay bestie, this is environment.d from the environment.d manual (section 5, for the record) — the whole tea on Definition of user service environment. it's giving "where do my env vars actually come from" and honestly? iconic. let's get into it 💅

---

✨ SYNOPSIS ✨

~/.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 🌸

so the config files hanging out in the environment.d/ directories? they hold lists of environment variable assignments that get passed to services started by the systemd user instance. systemd-environment-d-generator(8) is the one that parses them and updates the environment exported by the systemd user instance. and if you're wondering which processes actually inherit those variables — keep scrolling, bestie, it's discussed below. 👑

the user-level config directory defaults to ~/.config/environment.d/. if $XDG_CONFIG_HOME is set to an absolute path in the user service manager environment (like via PAM or /etc/environment), then it takes precedence over ~/.config/. but heads up, this creates a bootstrapping consideration: variables set in environment.d/ files — including $XDG_CONFIG_HOME itself — are not available when the generator figures out which directory to read. 🫠

It is recommended to use numerical prefixes for file names to simplify ordering.

and for backwards compatibility, a symlink to /etc/environment is installed, so that file gets parsed too. periodt. 💖

---

🌈 CONFIGURATION DIRECTORIES AND PRECEDENCE 🌈

config 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/.

all config files are sorted by their filename in lexicographic order, no matter which of the directories they live in. if multiple files specify the same option, the entry in the file with the lexicographically latest name wins. so basically the config in a certain file can 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's ordered later). choose your fighter 💅

packages should install their config files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs) [1]. files in /etc/ are reserved for the local administrator, who may use this logic to override the config files installed by vendor packages.

It is recommended to prefix all filenames with a two-digit number and a dash to simplify the ordering. 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.

if the administrator wants to disable a config file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the config directory in /etc/, with the same filename as the vendor config file. and if the vendor config file is included in the initrd image, the image has to be regenerated. don't forget that part, i'm begging 🫶

---

🎀 CONFIGURATION FORMAT 🎀

the config 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.

you can also 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 you can use "${FOO:+ALTERNATE_VALUE}" to expand to ALTERNATE_VALUE as long as "${FOO}" would have expanded to a non-empty value. you can escape a literal dollar sign "$" by doubling it, as in "$$". no cap. 💰

a backslash character "\" followed by a newline acts as a line continuation (both characters are discarded); in all other cases, the backslash is consumed and the following character is included literally in the value. this can be used to preserve leading/trailing whitespace or include literal backslashes. very demure, very mindful. ✨

you may optionally enclose the right hand side of assignments in pairs of either 'single quotes' or "double quotes"; these will be stripped from the value before saving it. using either quoting style does not affect variable expansion. however, single quotes disable backslash escaping entirely, while double quoting removes backslashes that precede double quotes """, dollar signs "$", backslashes "\", backticks "`", and newlines, and leaves all other backslashes in place. it's giving ✨surgery✨.

leading and trailing whitespace characters are stripped from both the left and right hand sides of the assignment. to preserve such spaces in the value, you can either enclose the entire value in quotes, or escape the space characters with backslashes. you can also include literal newlines in the value by enclosing it in quotes.

each KEY must be a valid variable name. empty lines and lines beginning with the comment characters "#" or ";" are ignored. no other elements of shell syntax are supported. don't try it. 🙈

💖 Examples 💖

Example 1. 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/}

Example 2. Escaping and variable expansion

/etc/environment.d/70-bar.conf:

# A comment
test_var=(variable)
; Another comment
test_comment=value # This is a part of the variable, and not a comment!

test_none= \ before\
after "" '' \${test_var}
test_double=" \ before\
after "" '' \${test_var}"
test_single=' \ before\
after "" '' \${test_var}'

# The above example produces the following environment variables, written using
# C-style string escapes:
#
# test_var="(variable)"
# test_comment="value # This is a part of the variable, and not a comment!"
# test_none=" beforeafter \"\" '' (variable)"
# test_double=" \\ beforeafter  '' (variable)"
# test_single=" \\ before\\\nafter \"\"  \\(variable)"

---

👑 APPLICABILITY 👑

environment variables exported by the user service manager (the 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 bestie: in general, systemd.service(5) units contain programs launched by systemd, and systemd.scope(5) 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 sshd(8) service builds an environment that is a combination of variables forwarded from the remote system and defined by sshd, see the discussion in ssh(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 config into programs they start, using systemctl show-environment or the underlying D-Bus call. the way that this works? chef's kiss. 💋

---

🌟 SEE ALSO 🌟

• systemd(1)
• systemd-environment-d-generator(8)
• systemd.environment-generator(7)

---

💀 NOTES 💀

1. 💣💥🧨💥💥💣 Please note that those configuration files must be available at all times. if /usr/local/ is a separate partition, it may not be available during early boot, and must not be used for configuration.

---

okay that's the whole page, bestie, you ate it up 🍓 this was systemd 262.1 tea, dated ENVIRONMENT.D(5) — go forth and export your little heart out, ily, mwah 💜🫶✨