[solved] How does gentoo w/systemd construct a user's PATH?

[equaeghe]

In another post, I discuss a problem I'm facing with setting the PATH for a user (actually for some GUI application that user is running): Cannot seem to update PATH using ~/.config/environment.d. It seems that this is not an easy issue to solve. So I'm trying to dig a bit deeper myself, which leads me to this post.

I'm wondering how gentoo with systemd constructs a user's path. I know that /etc/env.d and env-update create a set of environment variables for users, including a PATH. I've seen that that set of environment variables is copied to /etc/environment.d/10-gentoo-env.conf and assume that this is then picked up by systemd to create the actually used set of environment variables. Namely, combining it with the conf files in ~/.config/environment.d (all variables I set there are indeed picked up, except for PATH). Because the PATH I get is not updated/changed from the one generated by env-update, I'm wondering whether there is some step I am missing, which overrides the change to PATH I've made. By getting a full understanding on how a user's PATH is constructed, I could get to the bottom of this.

Any insights appreciated.

[flexibeast]

PATH is often set/modified via the user's shell, regardless of whether or not it's a systemd-based system. So if someone logs in from the console to a Bash shell, there are multiple files involved that can affect PATH, including ~/.bash_profile - refer to this section of the Bash manual for further details. If Zsh is being used, PATH might be set in ~/.zprofile. And so on.

i'm not sure what happens in the case of a graphical login (e.g. via a display manager like SDDM), rather than a console login, because i've not used a graphical login manager for decades.

[rab0171610]

I use systemd. I don't think systemd does anything specific with regards to path. The login program sets it to a default value from /etc/login.defs :

Code: Select all

#
# *REQUIRED*  The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH      PATH=/sbin:/bin:/usr/sbin:/usr/bin
ENV_PATH        PATH=/bin:/usr/bin

Other paths can be added to this default minimal path in concatenation with :$PATH . For example, from ~/.profile:

Code: Select all

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

I can't see the original post, it comes up as "The topic or post you requested does not exist". So I do not know how you were trying to add to the default $PATH variable or where it failed. I have never really had any issues doing that -- adding directories to $PATH. I don't think systemd is specifically involved unless maybe when using systemd-homed. I do not use it so I cannot say for sure.

[b11n]

I can't see the original post, it comes up as "The topic or post you requested does not exist".

Try this: https://forums.gentoo.org/viewtopic-t-1 ... ight-.html

[equaeghe]

I can't see the original post, it comes up as "The topic or post you requested does not exist".

I fixed the link, sorry about that. (Mixed up post and topic ids.)

[equaeghe]

I use systemd. I don't think systemd does anything specific with regards to path. The login program sets it to a default value from /etc/login.defs :

Code: Select all

#
# *REQUIRED*  The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH      PATH=/sbin:/bin:/usr/sbin:/usr/bin
ENV_PATH        PATH=/bin:/usr/bin

I do not think this code is used in current Gentoo systems. The Handbook says that /etc/env.d is where things are defined:

Code: Select all

grep -r ^PATH /etc/env.d/
/etc/env.d/50baselayout:PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin"
/etc/env.d/60llvm-9979:PATH="/usr/lib/llvm/20/bin"
/etc/env.d/60llvm-9978:PATH="/usr/lib/llvm/21/bin"

Then env-update concatenates these and passes them on. On systemd systems, this seems to be done via environment.d:

Code: Select all

$ grep -r ^PATH /etc/environment.d/
/etc/environment.d/10-gentoo-env.conf:PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin

This then in principle be merged with user modifications in ~/.config/environment.d:

Code: Select all

$ grep -r ^PATH ~/.config/environment.d/
/home/equaeghe/.config/environment.d/15-path.conf:PATH=$HOME/.local/bin:$PATH
/home/equaeghe/.config/environment.d/15-path.conf:PATHE=$PATH

But this last part is what is failing for me:

Code: Select all

$ systemctl --user show-environment | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin
PATHE=/home/equaeghe/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin

For some reason, PATH is overwritten again after systemd did its thing…

Other paths can be added to this default minimal path in concatenation with :$PATH . For example, from ~/.profile:

~/.profile does not get sources (for me). But for interactive shells, I (can) use .bashrc and that works:

Code: Select all

$ echo $PATH
/home/equaeghe/.config/carapace/bin:/home/equaeghe/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin

But this is not for setting GUI application environment variables and I have a mail client (KMail) for which I have defined my own filters in ~/.local/bin. The environment.d approach is meant to enable this kind of thing. I am trying to move to niri from KDE. KDE has its own facilities for setting the PATH and other environment variables for its applications (~/.config/plasma-workspace/env).

I'm becoming convinced Gentoo is doing something wrong here, overwriting my PATH. I guess I'll need to file a bug report.

[rab0171610]

I think you are over-complicating things. I simply pointed out how the $PATH variable gets set in Linux in general. In other words, it can be set by a multitude of cascading files that build on one another by adding to the $PATH variable. The lines from .profile were an example of how this is done in case you were doing it wrong.

If you want to add to it locally for a specific user, then all you have to do is set it in .bashrc using the format similar to the lines that exist in ~/.profile, as I pointed out by concatenation of your directories with the $PATH variable. You can put it in other files (.bash_profile), but just have those files sourced by your login shell or in your .bashrc . Leave the environment directories out of it for now.

For example:

Code: Select all

echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin

As an example, I wanted to add ~/Programs to my path. To do that I added the following to .bashrc:

Code: Select all

 PATH="$HOME/Programs:$PATH"

After logging out and logging back in again or sourcing the .bashrc file:

Code: Select all

source .bashrc

The path is now modified:

Code: Select all

/home/rab/Programs:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin

Why does this very basic, standard and normally reliable method of modifying or adding a directory to your path not work for you? I am not convinced that you need to have a directory added to your path through the environment method or for only when using kmail. You either need those directories persistent for your user or you don't need them at all. Normally kmail will be always running and checking for new mail most of the time anyway.

I'm becoming convinced Gentoo is doing something wrong here, overwriting my PATH. I guess I'll need to file a bug report.

I'm not convinced of that. I think if you insist on setting the path or adding to $PATH in the environment directories and env files, then it is not working as you expect because you are likely doing it wrong or don't understand the order of precedence. But if you feel that developers need to spend their time looking into it for you, then sure -- file a bug report.

[equaeghe]

If you want to add to it locally for a specific user, then all you have to do is set it in .bashrc using the format similar to the lines that exist in ~/.profile, as I pointed out by concatenation of your directories with the $PATH variable. You can put it in other files (.bash_profile), but just have those files sourced by your login shell or in your .bashrc . Leave the environment directories out of it for now.
[…]
Why does this very basic, standard and normally reliable method of modifying or adding a directory to your path not work for you? I am not convinced that you need to have a directory added to your path through the environment method or for only when using kmail. You either need those directories persistent for your user or you don't need them at all. Normally kmail will be always running and checking for new mail most of the time anyway.

The .bashrc approach does not work for GUI applications. I've got an update line for the PATH in my .bashrc and so

Code: Select all

$ echo $PATH
/home/equaeghe/.config/carapace/bin:/home/equaeghe/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin

However, for kmail:

Code: Select all

$ ps 1359
    PID TTY      STAT   TIME COMMAND
   1359 ?        Ssl    0:10 /usr/bin/kmail -qwindowtitle
$ cat /proc/1359/environ 
[…]PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/21/bin:/usr/lib/llvm/20/bin[…]

I could start kmail from within a bash session, but that's a kludgy workaround, not a fix.

There really is a reason why desktops like KDE have functionality like the ~/.config/plasma-workspace/env location for environment variable-modification scripts for GUI apps. I could still be wrong, but in this case, I really think the solution is really different from just adding a line to my .bashrc.

[rab0171610]

Nevermind. This is what I should be asking:

Why do you not explicitly set the path in the .desktop file or whatever method that you are using to launch kmail? In my example, the exec line for the desktop file would be:

Code: Select all

exec PATH="$HOME/Programs:$PATH" kmail

Then the command with the kmail PID should show the desired $PATH.
EDIT:
Just a note about KDE, if you are using KDE autostart to launch applications automatically at login (the desktop files are kept in ~/.config/autostart) you can add the environment variables to the entries in SystemSettings->System->Autostart . Just create a new entry for kmail and then edit the entry. When the dialog box pops up click on the Application tab and there is an space for entering the Environment Variables. Otherwise, if you do not autostart kmail for some reason you can keep a modified .desktop file with the $PATH environment variable for kmail in ~/.local/share/applications .

[equaeghe]

Why do you not explicitly set the path in the .desktop file or whatever method that you are using to launch kmail? In my example, the exec line for the desktop file would be:

Code: Select all

exec PATH="$HOME/Programs:$PATH" kmail

Good suggestion. I tried that earlier and it failed (kmail does not start). The reason is likely because one isn't allowed to have a second, unquoted ‘=’ in the Exec line or the variables are not expanded. A stackoverflow post suggests calling a shell to start the application:

Code: Select all

Exec=sh -c "PATH='$HOME/.local/bin:$PATH' kmail"

This works! (I still find it kludgy, as then I can't reuse the standard "kmail -qwindowtitle %c %u" invocation, as the shell cannot expand %c %u.)

Anyway, even this is not enough. Because calling my filters still failed, I looked a bit deeper and most likely the filters are run by another application, the akonadi-filter-agent, which does not have a desktop file… So I really need the environment.d approach or something equivalent to work…

Just a note about KDE, if you are using KDE autostart to launch applications automatically at login (the desktop files are kept in ~/.config/autostart) you can add the environment variables to the entries in SystemSettings->System->Autostart . […] Otherwise, if you do not autostart kmail for some reason you can keep a modified .desktop file with the $PATH environment variable for kmail in ~/.local/share/applications .

Thanks for the suggestion. I use the ~/.config/autostart directory (the autostarting is done by systemd), but I only ever add symlinks there to existing system or modified desktop files (the latter category indeed in ~/.local/share/applications).

[Hu]

The .bashrc approach does not work for GUI applications.

That's not exactly accurate. The bashrc approach works for bash, and processes started by bash, unless an intervening process clears out the environment. So as flexibeast noted at the beginning, if you log in on a text console and then start a GUI, your GUI will have descended from bash, and will have variables that were set by bash.[1] Conversely, if you use a login manager such that your GUI is spawned without any bash in the ancestry tree, then bashrc will never have been in effect for the GUI.

There really is a reason why desktops like KDE have functionality like the ~/.config/plasma-workspace/env location for environment variable-modification scripts for GUI apps.

Yes. It's to work around that they bypassed the traditional method of setting environment variables, at which point they had to reinvent the wheel.

A stackoverflow post suggests calling a shell to start the application:

Code: Select all

Exec=sh -c "PATH='$HOME/.local/bin:$PATH' kmail"

This works! (I still find it kludgy, as then I can't reuse the standard "kmail -qwindowtitle %c %u" invocation, as the shell cannot expand %c %u.)

You don't need the shell to expand those. Expanding those percent-specifiers is the job of whatever custom tool is parsing a .desktop file. What happens if you write:

Code: Select all

Exec=/bin/sh -c "PATH='$HOME/.local/bin:$PATH' kmail "$@"" -- -qwindowtitle %c %u

You may need to experiment with the quoting, since I don't know how the Exec= parser will handle nested quotes. The goal is for the shell to see, as one argument, the string PATH='$HOME/.local/bin:$PATH' kmail "$@", so that $@ is considered quoted. You might also need to quote %c and/or %u, depending on what their expanded value is and whether your Exec= parser tries to do word-splitting on an unquoted expanded value.

[1]: GNOME does something weird here. When last I was stuck using it, they seem to do an IPC to systemd to start the process instead of starting it directly, at which point the process isn't descended from bash. It's descended from systemd.

[pingtoo]

I think Gentoo did very little on altering systemd default behavior. So you are looking systemd specific design.

IMHO, using

Code: Select all

Exec=sh -c "PATH='$HOME/.local/bin:$PATH' kmail"

is smart workaround, however it is side way for today's DE/systemd environment.

If you believe place environment variable changes in ~/.config/environment.d/XXX.conf file did not work as your expect, then we should debug why it did not work. for debugging we need to understand the specific method of how do you envision launch your application with the altered environment variables.

Sometime the procedure that trying to examine, could lead to misunderstanding what the real problem is. Because the examine method as well as the timing could lead to wrong impression of changing effect.

[rab0171610]

To be clear, I did not launch it using a desktop file or through KDE autostart. I did it from the command line:

Code: Select all

 PATH="$HOME/Programs:$PATH" kmail

I incorrectly assumed the exec line in a desktop file would be identical. I did not know the parenthesis would be a problem until you tried it and reported back that it did not work.

On a side note, the KDE autostart by default utilizes systemd service generator when launching programs. Initially, this could be bypassed allowing for a traditional autostart without using systemd. This could be turned off by editing ~./config/startkderc and setting:

Code: Select all

[General]
systemdBoot=false

I have had this entry since it was announced in 2020 and the kde autostart still does not use systemd on my machine as far as I can tell:

Code: Select all

systemctl --user status plasma-plasmashell.service
○ plasma-plasmashell.service
     Loaded: masked (Reason: Unit plasma-plasmashell.service is masked.)
     Active: inactive (dead)

This might not be optional in the future.
Read more about the function and history of it here:
https://blog.davidedmundson.co.uk/blog/ ... d-startup/

Users can also bypass the KDE autostart generator service if they do not want to launch services for every desktop file on the system. This can be done by editing the .desktop file and adding X-systemd-skip=true or Hidden=true .

Code: Select all

Entry 	                           Handling
Hidden=, X-systemd-skip= 	     No service will be generated if set to true

https://man.archlinux.org/man/systemd-x ... rator.8.en

(I do not need systemd to scan for every desktop file on the system and launch a service for every application automatically. I do not want systemd launching these kinds of services at all. As well, I had issues with this method that disrupted my workflow so I disabled all of it. Specifically I had issues with rogue services/app-slices not stopping on logout or shutdown, app service conflicting with my ability to control the program from the command line using the PID, systemd launching a service for a bash script used to start a program, etc)

This applies to what I was about to add. For some applications, users can create a bash script that launches the program and have that as the exec line in the desktop file. Or they can set KDE autostart to launch the bash script at login. This bash script can exit or can detach after launching the application (detach or exit or application_name&). A sleep entry can also be added initially (sleep x &&) if the user wants to use bash to wait before launching the application. I use bash scripts to launch applications for a variety of reasons. One is to set the environment variable to force Xwayland under certain circumstances but not others. I do not want to edit desktop files or autostart entries in this case. So I use a bash script to set the variable to force Xwayland and then launch the program and then have the script detach from the process or exit.

I point this out because in case of the bash script, the punctuation i.e double quotes should not be an issue.
For example, a file called kmail.sh :

Code: Select all

#!/bin/bash
PATH="$HOME/.cups:$PATH" kmail&

Should launch kmail with the modified $PATH .

[flexibeast]

Code: Select all

#
# *REQUIRED*  The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH      PATH=/sbin:/bin:/usr/sbin:/usr/bin
ENV_PATH        PATH=/bin:/usr/bin

I do not think this code is used in current Gentoo systems.

login.defs(5) is a configuration file for login(1):

CONFIG FILE ITEMS

login reads the /etc/login.defs configuration file (see login.defs(5)).

So the contents of login.defs will be processed unless a system is not using login(1) for logging in.

i just had a look at the sources for SDDM, GDM, and greetd. For SDDM, the only references to login.defs i could immediately find are in CMakeList.txt, for the UID_MIN and UID_MAX variables. i couldn't find any references to login.defs in GDM, nor in greetd. i guess it's possible that they're all using some library / whatever to indirectly access login.defs; i haven't examined their sources in detail.

[equaeghe]

So after further investigation, by default Gentoo with systemd properly uses environment.d processing (and env-update makes sure /etc/profile.env variables are included). However, window manager and desktop environments do all kinds of stuff on startup. In my case it was niri importing /etc/profile.env again, overwriting modified environment variables <https://bugs.gentoo.org/969230>.