Wrong PATH in GNOME Terminal

In a GNOME X session, when I open the GNOME Terminal application, the shell does not have the values I would expect in the PATH Environment Variable.

Looking at /etc/profile, I would expect the PATH variable to contain the User’s bin directory ($HOME/bin), but instead I am seeing:

# echo $PATH

I believe something is setting the PROFILEREAD variable too early because if I unset that variable, I can source my User .profile file (which sources /etc/profile) and see the values I would expect:

# . ~/.profile
# echo $PATH

Also, connecting via SSH yields the correct values in the PATH variable.

I have been searching /etc for lines that would set or reset the PATH or PROFILEREAD variables like this, but I am not having luck.

Normally, “/etc/profile” is processed while setting up your GUI session. And that’s when you would expect $PROFILEREAD to be set. But $PATH should also be set at that time.

I would expect that, too. Perhaps something is running after processing /etc/profile to re-set the PATH variable.


what about your dotfiles in your** $HOME** directory? maybe something in there?

Check “.profile” and “.bashrc” and “.bash_profile” or even “.bash_login” in your home directory (if those exist).

Removing unnecessary lines:


if test -z "$PROFILEREAD"; then
        . /etc/profile || true


test -s ~/.alias && . ~/.alias || true

export HISTCONTROL=erasedups
export HISTIGNORE=$' 	]*:[fb]g:history*:exit:ls' # Ignore the ls command as well
shopt -s histappend


alias cp='cp --preserve=timestamps'

My profile does not contain ~/.bash_profile or ~/.bash_login. No other dotfiles of note, except maybe .xinitrc.template. Would anything in ~/.local/ or ~/.share/ likely affect this?

Works as expected on clean Leap 15.1 installation both in X11 and Wayland sessions. Try new user with clean home directory.

I would not expect them to be relevant. Those usually apply to specific applications.

But maybe test some other terminal application, to see if that is also affected (it probably is). You probably have “xterm” installed, so try that (just as a test).


Try looking for files with *.local extensions in /etc

find /etc/ -type f -name '*.local' 2>/dev/null

I remembers installing one program that creates bashrc.local and added It’s** PATH** in there, that was years ago so I can’t really remember which one is it.

I do have a few *.local files, like bash.bashrc.local, but none of those is setting or appending to the PATH variable anywhere.

As an additional data point, the environment sets the PATH variable correctly on first login, but I only encounter the incorrect PATH values after logging out and logging in again.

I was able to reproduce it exactly once. All subsequent attempts resulted in PATH from /etc/profile. The other PATH is default that GDM is using during user logon. Neither using Wayland nor X11, neither on Leap nor on TW.

So you need to start with describing your environment in as much details as possible. What display manager you are using, are you using auto-logon or not, are you using Wayland, X11 or GNOME-classic session, what is your login shell, how many times you need to log out and log in before it happens, does it happen with every user (including new one) or not, are there any other sessions when you observe it etc etc. IOW if you want someone to fix it, you need to find how to reliably reproduce it on another system.

It turns out that my first GNOME session had a process that wouldn’t terminate properly on logoff, keeping the session in a perpetual terminating state.

> loginctl # To list sessions and retrieve Session ID (number)
> loginctl show-session #] | grep -F -e 'Active=' -e 'State='
> ps -u [UID] # Find which processes are still running

I don’t exactly know why this resulted in setting the Environment Variables for any new GNOME session with the same user to the values for GDM, but causing the process to terminate allowed setting the Environment Variables to the values I would expect for any new GNOME session for that user.

Any reason you stripped out all information that allows someone to troubleshoot and possibly reproduce this issue?

More precisely - the problem happens when systemd user instance is not terminated together with GNOME session. There are pretty legitimate use cases (concurrent remote session, linger enabled) beyond rogue process. First session leaves PROFILEREAD environment variable set so any subsequent processing of /etc/profile skips fragments guarded by this variable. One of them sets PATH.

I know why it happens (at least using GDM/GNOME, you never bothered to provide any details about your environment). Open bug report on openSUSE bugzilla and give link here, I’ll add detailed explanation. I do not expect any easy quick fix though.

As a workaround, simply set PATH you need in ~/.profile. Using different display manager like lightdm may work too.

Please check “/etc/systemd/logind.conf”.

  • Add user entries to “KillOnlyUsers=”.

[HR][/HR]Yes, there’s a systemd issue here where, not all user processes are killed automatically by the system on logout …

  • Because, there was a reluctance to do this by default “for everyone” «including the user “root” – which would lead to a dead system … » – the “logind.conf” parameter is “KillUserProcesses=no” – default of “no” …