Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#56716 - [filesystem]: Export variables set via */environment.d/*.conf files

Attached to Project: Arch Linux
Opened by Philipp Reinkemeier ( - Thursday, 14 December 2017, 10:24 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 16 December 2017, 16:09 GMT
Task Type Feature Request
Category Packages: Core
Status Assigned
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 4
Private No


filesystem provides /etc/profile setting environment variables.
Recently, systemd got a new feature for configuring environment
variables via */environment.d/*.conf files. Environment variables
configured via these files end up in the environment block of
the systemd user manager. Thus, every service executed by it
is aware of them. However, up to now, these environment variables
do not necessarily end up in login sessions. For instance if
one logs in via the console or ssh, these environment variables
are not set. On the other hand gnome seems to import them
along with also executing a login shell, thus reading /etc/profile.
This leads to the problem mentioned in The environment
variable PATH, if configured via e.g. some file in ~/.config/environment.d/
is overwritten, because /etc/profile is executed as well. On
the other hand an environment variable PATH1 would have a value as

This feature request is about to make sure that environment variables
have consistent values, independently of whether one logs in via the
console or some graphical session.
A way to achieve this would be to add the following line to /etc/profile
right after the execution of scripts in /etc/profile.d/:

export $(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)

A user can then configure environment variables either via the logic provided
by systemd or via ~/.profile. Further, this opens up the possibility to smoothly
migrate some scripts in /etc/profile.d to the systemd-logic of setting environment
variables. Examples of such scripts are "", "libreoffice-*.sh", "",
"", ...
Thus, environment variables seen by services executed by the systemd user manager
process would get consistent with the ones seen in login sessions.

Additional info:
* filesystem 2017.10-2

Steps to reproduce:
1. Create a file ~/.config/environment.d/10-path.conf with
the following content PATH=foo${PATH:+:$PATH}
and PATH1=foo${PATH:+:$PATH}
2. Log into gnome and execute env in a terminal.
One gets PATH=X and PATH1=foo:X.
3. Login via getty and execute env.
One gets PATH=X and PATH1 is not defined.
Expected would be PATH=foo:X and PATH1=foo:X in
both cases.
This task depends upon

Comment by Eli Schwartz (eschwartz) - Monday, 25 December 2017, 21:07 GMT
Is this still a problem after  FS#47884 ? /etc/profile no longer overwrites the existing $PATH...
Comment by Sébastien Luttringer (seblu) - Monday, 25 December 2017, 21:13 GMT
This looks like a feature request, not a bug/problem.
Comment by Eli Schwartz (eschwartz) - Monday, 25 December 2017, 21:19 GMT
"The environment variable PATH, if configured via e.g. some file in ~/.config/environment.d/ is overwritten, because /etc/profile is executed as well." --> no longer should happen, I believe.

Shouldn't user sessions already be loading this or something anyway? I mean, that kind of looks like what an environment.d generator would be supposed to do in the first place.
Comment by Philipp Reinkemeier ( - Friday, 29 December 2017, 19:27 GMT
@Eli Schwartz: "Is this a problem after  FS#47884  ? /etc/profile no longer overwrites the existing $PATH"

Yes and no:

No, because probably PATH is no longer overwritten (i did not test it, but the solution in
looks good iff there's no other place where PATH is not extended but set to a fixed value).

Yes, because there is a discrepancy in environment variables picked up by different sessions e.g. gnome and login and ssh. The problem is that gnome picks up the configurations done in e.g. ~/.config/environment.d/ and ~/.profile, while logging in via the console (ultimately executing login, which executes the shell specified in /etc/passwd) does NOT consider ~/.config/environment.d/ in any way, but executes ~/.profile. This feature request is mainly about making environment variable configurations more consistent across different session types ("more" because currently there does not seem to be a way to enforce application of environment variable configurations in all different types of login sessions in a secure way as discussed upstream
Currently the user can only use ~/.profile to set environment variables consistently for at least console and gnome sessions. Implementing the proposal above should make it possible for the user to choose whether he/she wants to use ~/.profile or ~/.config/environment.d/, both would work.
Comment by Sébastien Luttringer (seblu) - Tuesday, 21 May 2019, 15:23 GMT
Looks like upstream is well aware[1] that these user-env-generators doesn't provide a solution for having the same environment when login between desktop/login/ssh.

We could eventually improve the situation by loading them into our profile shell. This require to load all user generators and not only 30-systemd-environment-d-generator.

Comment by marc boocha (marcthe12) - Friday, 11 September 2020, 12:44 GMT
I have snip bit in my /etc/profile:
set -a
eval "$(systemctl --user show-environment)"
set +a

The big problem here is to prevent code injection by systemctl --user show-environment. Also upstream gnome wayland does not even read /etc/profile anymore and directly gets it from the dbus call which is equillant to this function.