# environment.d

## NAME



           environment.d - Definition of user service environment
    


## 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



           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-generator(8) 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 DIRECTORIES AND PRECEDENCE



           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/.
    
           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).
    
           Packages should install their configuration 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 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. 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 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.
    


## 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**
           **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/}
    


## 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.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
           configuration into programs they start, using **systemctl**
           **show-environment** or the underlying D-Bus call.
    


## 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.
    


* * *