Question about Environment Variables

Simaryp · 2021-01-04 11:33:16

I want to manage some environment variables and since I am currently swtiching between gnome and sway I wanted to take a DE and DM agnostic approach.
So I created a .conf file in .config/environment.d/ and placed everything there.

If I compare the output of printenv and systemctl --user show-environment everything from the systemctl command is also in output of printenv with the same values except for PATH.

I put PATH=$HOME/.local/bin:$PATH in my environment.d and it shows up in the systemctl --user command. But in printenv my custom path is missing.

I wonder whether this is a bug or expected behavior. I added the path for my python libraries and I can now eg. import numpy, although the .local/bin is not in path.

Trilby · 2021-01-04 13:00:01

How do you start python? Or more importantly/directly, are the python path changes present in the printenv output in a terminal?

If the changes in the python variables, but not PATH, are present in the terminal, that would mean something in your shell configs is overriding the previous setting. Post your shell configs.

Simaryp · 2021-01-04 15:27:08

Ah sorry about the confusion regarding python. I didn't needed it for numpy but for flake8.

So it's not working at all no matter whether I have the PATH in environment.d.

Here is environment.d:

PATH=$HOME/.local/bin:$PATH
MOZ_ENABLE_WAYLAND=1
QT_QPA_PLATFORM=wayland
QT_WAYLAND_FORCE_DPI=96
QT_WAYLAND_DISABLE_WINDOWDECORATION=1
QT_QPA_PLATFORMTHEME=qt5ct

bashrc

#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --color=auto'
PS1='[\u@\h \W]\$ '
alias config='/usr/bin/git --git-dir=/home/jacob/.cfg/ --work-tree=/home/jacob'

bash_profile
#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

Did some research. Seems to be this bug https://github.com/systemd/systemd/issues/6414

Last edited by Simaryp (2021-01-04 18:33:13)

seth · 2021-01-04 16:02:40

Please use code tags, https://bbs.archlinux.org/help.php#bbcode

The linked bug is about bash being invoked as login shell and debian hardcoding $PATH in /etc/profile
Doe the login shell condition fit your case?
What's

grep -r PATH /etc/profile*

(this should™ not happen w/ the arch profile… files)

Trilby · 2021-01-04 16:15:02

Ah ... so, do you have any reason to believe that ~/.config/environment.d/*.conf files should be loaded in your shell session? I don't, and they are not here.

These should only be available in the shell session if they happen to be inherited from a parent process. And this may be the case if you are running a graphical terminal within a graphical (e.g., Xorg) session that was started as a systemd user service. But otherwise these values would not likely be set in any parent process of the shell session.

Simaryp · 2021-01-04 18:30:51

grep -r PATH /etc/profile*
/etc/profile:# Append "$1" to $PATH when not already in.
/etc/profile:    case ":$PATH:" in
/etc/profile:            PATH="${PATH:+$PATH:}$1"
/etc/profile:# Force PATH to be environment
/etc/profile:export PATH
/etc/profile:unset MANPATH
/etc/profile.d/gawk.sh:	unset AWKPATH
/etc/profile.d/gawk.sh:	export AWKPATH=`gawk 'BEGIN {print ENVIRON["AWKPATH"]}'`
/etc/profile.d/gawk.sh:	[ -z "$AWKPATH" ] && AWKPATH=`gawk 'BEGIN {print ENVIRON["AWKPATH"]}'`
/etc/profile.d/gawk.sh:	export AWKPATH="$*:$AWKPATH"
/etc/profile.d/gawk.sh:	[ -z "$AWKPATH" ] && AWKPATH=`gawk 'BEGIN {print ENVIRON["AWKPATH"]}'`
/etc/profile.d/gawk.sh:	export AWKPATH="$AWKPATH:$*"
/etc/profile.d/gawk.sh:	unset AWKLIBPATH
/etc/profile.d/gawk.sh:	export AWKLIBPATH=`gawk 'BEGIN {print ENVIRON["AWKLIBPATH"]}'`
/etc/profile.d/gawk.sh:	[ -z "$AWKLIBPATH" ] && \
/etc/profile.d/gawk.sh:		AWKLIBPATH=`gawk 'BEGIN {print ENVIRON["AWKLIBPATH"]}'`
/etc/profile.d/gawk.sh:	export AWKLIBPATH="$*:$AWKLIBPATH"
/etc/profile.d/gawk.sh:	[ -z "$AWKLIBPATH" ] && \
/etc/profile.d/gawk.sh:		AWKLIBPATH=`gawk 'BEGIN {print ENVIRON["AWKLIBPATH"]}'`
/etc/profile.d/gawk.sh:	export AWKLIBPATH="$AWKLIBPATH:$*"
/etc/profile.d/perlbin.csh:[ -d /usr/bin/site_perl ] && setenv PATH ${PATH}:/usr/bin/site_perl
/etc/profile.d/perlbin.csh:[ -d /usr/bin/vendor_perl ] && setenv PATH ${PATH}:/usr/bin/vendor_perl
/etc/profile.d/perlbin.csh:[ -d /usr/bin/core_perl ] && setenv PATH ${PATH}:/usr/bin/core_perl
/etc/profile.d/flatpak-bindir.sh:  PATH="$PATH:$HOME/.local/share/flatpak/exports/bin"
/etc/profile.d/flatpak-bindir.sh:  PATH="$PATH:/var/lib/flatpak/exports/bin"
/etc/profile.d/jre.sh:export PATH=${PATH}:/usr/lib/jvm/default/bin
/etc/profile.d/jre.csh:setenv PATH "${PATH}:/usr/lib/jvm/default/bin"
/etc/profile.d/gawk.csh:alias gawkpath_default 'unsetenv AWKPATH; setenv AWKPATH `gawk -v x=AWKPATH "BEGIN {print ENVIRON[x]}"`'
/etc/profile.d/gawk.csh:alias gawkpath_prepend 'if (! $?AWKPATH) setenv AWKPATH ""; if ($AWKPATH == "") then; unsetenv AWKPATH; setenv AWKPATH `gawk -v x=AWKPATH "BEGIN {print ENVIRON[x]}"`; endif; setenv AWKPATH "\!*"":$AWKPATH"'
/etc/profile.d/gawk.csh:alias gawkpath_append 'if (! $?AWKPATH) setenv AWKPATH ""; if ($AWKPATH == "") then; unsetenv AWKPATH; setenv AWKPATH `gawk -v x=AWKPATH "BEGIN {print ENVIRON[x]}"`; endif; setenv AWKPATH "$AWKPATH"":\!*"'
/etc/profile.d/gawk.csh:alias gawklibpath_default 'unsetenv AWKLIBPATH; setenv AWKLIBPATH `gawk -v x=AWKLIBPATH "BEGIN {print ENVIRON[x]}"`'
/etc/profile.d/gawk.csh:alias gawklibpath_prepend 'if (! $?AWKLIBPATH) setenv AWKLIBPATH ""; if ($AWKLIBPATH == "") then; unsetenv AWKLIBPATH; setenv AWKLIBPATH `gawk -v x=AWKLIBPATH "BEGIN {print ENVIRON[x]}"`; endif; setenv AWKLIBPATH "\!*"":$AWKLIBPATH"'
/etc/profile.d/gawk.csh:alias gawklibpath_append 'if (! $?AWKLIBPATH) setenv AWKLIBPATH ""; if ($AWKLIBPATH == "") then; unsetenv AWKLIBPATH; setenv AWKLIBPATH `gawk -v x=AWKLIBPATH "BEGIN {print ENVIRON[x]}"`; endif; setenv AWKLIBPATH "$AWKLIBPATH"":\!*"'
/etc/profile.d/perlbin.sh:export PATH

@Trilby: I thought that's the case because this was one of the recommended ways to set environment variables while using a DM. And for all other variables beside PATH that acually works eg.:

$ echo $QT_QPA_PLATFORMTHEME 
qt5ct

seth · 2021-01-04 21:40:11

Doesn't look like a static PATH export.

Let's see the value for the terminal emulator:

grep -z PATH /proc/$PPID/environ

Also

loginctl session-status

Trilby · 2021-01-04 21:43:33

Simaryp wrote:

I thought that's the case because this was one of the recommended ways to set environment variables while using a DM.

This may be the case - which DM then. DMs' primary purpose seems to be to malfunction. But in your first post you said you were looking for a DM/DE agnostic approach. Is that no longer the case?

Simaryp wrote:

And for all other variables beside PATH that acually works

That's what I was asking in my first response (RE python). Are you sure QT_QPA_PLATFORMTHEME isn't set elsewhere too? Can you put a completely made up / gibberish variable in your ~/.config/profile.d/ (e.g., FOO=bar) to see if that variable is inherited by your shell session?

Simaryp · 2021-01-05 05:35:25

Sorry that might have been misleading. Currently I am using GDM. And since I am still trying out sway I want to keep it like that for a while. If I kept using sway for some longer time and think I will stick with it, I might change that and replace it with greetd or some other thing. That's why I want a solution for that task that works no matter whether I launch sway via GDM, a TUI or simply tty.
And since I tried also for other topics like mounting, scheduling tasks etc. to adapt to systemd I thought that might be the modern way to go.

I can make up a variable and test it, but I am already super sure that it''s like that. It seems for some variables it isn't sufficient to set them while sway is already running and reload the sway conf. Eg. some QT stuff never did anything. Firstly, when I set them up using systemd and rebooted they had any effect at all.

loginctl session-status
3 - jacob (1000)
           Since: Mon 2021-01-04 20:44:48 CET; 9h ago
          Leader: 1154 (gdm-session-wor)
            Seat: seat0; vc2
             TTY: tty2
         Service: gdm-password; type wayland; class user
           State: active
            Unit: session-3.scope
                  ├─1154 gdm-session-worker [pam/gdm-password]
                  ├─1189 /usr/bin/gnome-keyring-daemon --daemonize --login
                  ├─1193 /usr/lib/gdm-wayland-session --register-session sway
                  ├─1197 sway
                  ├─1208 swayidle -w timeout 300 swaylock --screenshots --clock --indicator --indicator-radius 100 --indicator-thickness 7 --effect-blur 7x5 --effect-vignette 0.5:0.5 --ring-color ad8641 --key-hl->
                  ├─1216 nm-applet --indicator
                  ├─1218 /usr/bin/python /usr/bin/blueman-applet
                  ├─1312 /usr/bin/python /usr/bin/blueman-tray
                  ├─1398 /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh
                  ├─1432 /usr/lib/firefox/firefox
                  ├─1446 Xwayland :0 -rootless -terminate -listen 22 -listen 24 -wm 64
                  ├─1587 /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 177 -prefMapSize 240098 -parentBuildID 20201222034653 -appdir /usr/lib/firefox/browser 1432 true tab
                  ├─1768 /usr/lib/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 7353 -prefMapSize 240098 -parentBuildID 20201222034653 -appdir /usr/lib/firefox/browser 1432 true tab
                  ├─1955 /usr/lib/firefox/firefox -contentproc -childID 9 -isForBrowser -prefsLen 7353 -prefMapSize 240098 -parentBuildID 20201222034653 -appdir /usr/lib/firefox/browser 1432 true tab
                  ├─2001 /usr/bin/keepassxc
                  ├─2040 /usr/bin/keepassxc-proxy /home/jacob/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json keepassxc-browser@keepassxc.org
                  ├─2050 /usr/bin/evolution
                  ├─2094 /usr/lib/evolution-data-server/evolution-alarm-notify
                  ├─2134 /usr/bin/xdg-dbus-proxy --args=51
                  ├─2139 /usr/bin/xdg-dbus-proxy --args=52
                  ├─2143 /usr/bin/bwrap --args 52 -- /usr/lib/WebKitWebProcess 7 40
                  ├─2147 /usr/bin/bwrap --args 52 -- /usr/lib/WebKitWebProcess 7 40
                  ├─2149 /usr/lib/WebKitNetworkProcess 8 40
                  ├─2152 /usr/lib/WebKitWebProcess 7 40
                  ├─3711 swaybg -o * -i /home/jacob/.config/wallpaper.png -m fill
                  ├─3713 waybar -b bar-0
                  ├─4283 /usr/lib/firefox/firefox -contentproc -childID 19 -isForBrowser -prefsLen 9938 -prefMapSize 240098 -parentBuildID 20201222034653 -appdir /usr/lib/firefox/browser 1432 true tab
                  ├─4329 /usr/lib/firefox/firefox -contentproc -childID 20 -isForBrowser -prefsLen 9938 -prefMapSize 240098 -parentBuildID 20201222034653 -appdir /usr/lib/firefox/browser 1432 true tab
                  ├─4387 /usr/lib/firefox/firefox -contentproc -childID 21 -isForBrowser -prefsLen 9938 -prefMapSize 240098 -parentBuildID 20201222034653 -appdir /usr/lib/firefox/browser 1432 true tab
                  ├─5512 kitty
                  ├─5529 /bin/bash
                  ├─5562 loginctl session-status
                  └─5563 less

Jan 05 06:21:11 taschenrechner waybar[3713]: Status Notifier Item with bus name ':1.28' and object path '/org/ayatana/NotificationItem/blueman' is already registered
Jan 05 06:21:11 taschenrechner waybar[3713]: Status Notifier Item with bus name ':1.28' and object path '/org/ayatana/NotificationItem/blueman' is already registered
Jan 05 06:21:11 taschenrechner waybar[3713]: Status Notifier Item with bus name ':1.28' and object path '/org/ayatana/NotificationItem/blueman' is already registered
Jan 05 06:21:12 taschenrechner waybar[3713]: Status Notifier Item with bus name ':1.28' and object path '/org/ayatana/NotificationItem/blueman' is already registered
Jan 05 06:21:12 taschenrechner waybar[3713]: Status Notifier Item with bus name ':1.28' and object path '/org/ayatana/NotificationItem/blueman' is already registered
Jan 05 06:21:17 taschenrechner evolution[2050]: Connection established.  Going online.
Jan 05 06:21:18 taschenrechner /usr/lib/gdm-wayland-session[1208]: Releasing sleep lock 11
Jan 05 06:21:18 taschenrechner /usr/lib/gdm-wayland-session[1208]: Got sleep lock: 12
Jan 05 06:21:49 taschenrechner keepassxc[2001]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
Jan 05 06:31:10 taschenrechner /usr/lib/gdm-wayland-session[5512]: [005 06:31:10.277430] [glfw error 65549]: Wayland: Window attention request not implemented yet

$ grep -z PATH /proc/$PPID/environ
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin[jacob@taschenrechner ~]$

seth · 2021-01-05 09:53:29

grep -z PATH /proc/1197/environ # sway
grep -z PATH /proc/1193/environ # gdm-wayland-session
grep -z PATH /proc/1154/environ # gdm-session-worker

If you rebooted or restarted the session, please ensure to use the updated PIDs.

Simaryp · 2021-01-05 11:45:13

$ grep -z PATH /proc/1197/environ # sway
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin
 
$ grep -z PATH /proc/1193/environ # gdm-wayland-session
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin
 
$ grep -z PATH /proc/1154/environ # gdm-session-worker
grep: /proc/1154/environ: Keine Berechtigung

$ sudo grep -z PATH /proc/1154/environ # gdm-session-worker
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin

Despite of the order for the last one they are all the same.

$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin

Last edited by Simaryp (2021-01-05 11:47:28)

seth · 2021-01-05 15:06:00

https://wiki.archlinux.org/index.php/En … nvironment

The factual accuracy of this article or section is disputed.
Reason: environment.d(5) only affects systemd user services.[2] Setting up environment variables listed in ~/.config/environment.d/ on Wayland sessions is GDM-specific behavior. (Discuss in Talk:Environment variables#)

Looks like a GDM "hack" that might simply no longer apply?

Trilby · 2021-01-05 16:40:24

seth wrote:

Looks like a GDM "hack" that might simply no longer apply?

If that's the case, though, other variables set in that file would also not be set. The OP claims (but doesn't seem to want to test) that they are.

Simaryp · 2021-01-05 17:36:23

Trilby wrote:

seth wrote:
Looks like a GDM "hack" that might simply no longer apply?
If that's the case, though, other variables set in that file would also not be set. The OP claims (but doesn't seem to want to test) that they are.

Oh sry, I forgot that request:

$ printenv
SHELL=/bin/bash
COLORTERM=truecolor
QT_WAYLAND_DISABLE_WINDOWDECORATION=1
I3SOCK=/run/user/1000/sway-ipc.1000.1189.sock
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
DESKTOP_SESSION=sway
XCURSOR_SIZE=24
XDG_SEAT=seat0
PWD=/home/jacob
LOGNAME=jacob
XDG_SESSION_DESKTOP=sway
QT_QPA_PLATFORMTHEME=qt5ct
XDG_SESSION_TYPE=wayland
MOTD_SHOWN=pam
GDM_LANG=de_DE.UTF-8
FOO=bar
HOME=/home/jacob
USERNAME=jacob
LANG=de_DE.UTF-8
SWAYSOCK=/run/user/1000/sway-ipc.1000.1189.sock
WAYLAND_DISPLAY=wayland-0
KITTY_WINDOW_ID=1
QT_QPA_PLATFORM=wayland
XDG_SESSION_CLASS=user
TERMINFO=/usr/lib/kitty/terminfo
TERM=xterm-kitty
USER=jacob
QT_WAYLAND_FORCE_DPI=96
DISPLAY=:0
SHLVL=1
MOZ_ENABLE_WAYLAND=1
XDG_VTNR=2
XDG_SESSION_ID=3
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/home/jacob/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin
GDMSESSION=sway
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/jacob
_=/usr/bin/printenv

$ cat .config/environment.d/envvars.conf
PATH=$HOME/.local/bin:$PATH
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
MOZ_ENABLE_WAYLAND=1
QT_QPA_PLATFORM=wayland
QT_WAYLAND_FORCE_DPI=96
QT_WAYLAND_DISABLE_WINDOWDECORATION=1
QT_QPA_PLATFORMTHEME=qt5ct
FOO=bar

I am also open for a better solution that is independent of the actual login process.

seth · 2021-01-05 17:39:39

The weird thing is that $PATH isn't updated anywhere in the session chain…
What if you hardcode $HOME ("/home/jacob")?

Simaryp · 2021-01-05 18:32:22

Tried it didn't work.

Maybe thats the reason?

If I create a .pamenvironment file in ~/, is this read no matter what the login method will be?

What is actually the recommended up to date universal way to set those variables?

Last edited by Simaryp (2021-01-05 18:42:28)

seth · 2021-01-05 21:16:34

Looks like you found the bug.

What is actually the recommended up to date universal way to set those variables?

For GDM:
https://help.gnome.org/admin/gdm/stable … on.html.en
PreSession

As for "universal" try /etc/profile.d/

Last edited by seth (2021-01-05 21:16:47)

Simaryp · 2021-01-06 12:44:01

Hmm don't want to dive in the gdm abyss.

But everything in /etc will be globally right?

seth · 2021-01-06 14:36:39

/etc is a system path, not a user path.
But it can be shadowed by the latter and just putting environments somewhere won't add them either.

But environment exports in /etc/profile.d/somefile.sh will show up pretty much everywhere, yes.

Edit there's also https://wiki.archlinux.org/index.php/En … ng_pam_env

Last edited by seth (2021-01-06 14:38:30)

Trilby · 2021-01-06 15:43:50

Simaryp wrote:

What is actually the recommended up to date universal way to set those variables?

And there's the rub. Environment variables are so named because they exist within a given environment. They are - by definition - not global and not universal. You need to determine what environment you want them set in, and set them there. You may put them in a given file and import that file into numerous environments, but the only way to make them truly global would be for the kernel to set them during boot up (prior to init). Having pid1 set and export variables would have them set for all userspace programs, but I don't think systemd has a mechanism to do this. Anything other than that cannot and will not be "global" or "universal".

/etc/profile(.d) was the proper way to set variables that one wanted for all programs ran by a user after they logged in. But systemd's mechanisms of launching DMs breaks this. So now you need to work around that and use one method for setting variables for login shell sessions (and all child processes) and another for DM sessions (and all child processes). Again, you could store the variables in one file and import them into both environments - this allows you to set them all in one place - but they are not "global" or "universal", they just happen to be shared by two different process lineages.

Arch Linux

#1 2021-01-04 11:33:16

Question about Environment Variables

#2 2021-01-04 13:00:01

Re: Question about Environment Variables

#3 2021-01-04 15:27:08

Re: Question about Environment Variables

#4 2021-01-04 16:02:40

Re: Question about Environment Variables

#5 2021-01-04 16:15:02

Re: Question about Environment Variables

#6 2021-01-04 18:30:51

Re: Question about Environment Variables

#7 2021-01-04 21:40:11

Re: Question about Environment Variables

#8 2021-01-04 21:43:33

Re: Question about Environment Variables

#9 2021-01-05 05:35:25

Re: Question about Environment Variables

#10 2021-01-05 09:53:29

Re: Question about Environment Variables

#11 2021-01-05 11:45:13

Re: Question about Environment Variables

#12 2021-01-05 15:06:00

Re: Question about Environment Variables

#13 2021-01-05 16:40:24

Re: Question about Environment Variables

#14 2021-01-05 17:36:23

Re: Question about Environment Variables

#15 2021-01-05 17:39:39

Re: Question about Environment Variables

#16 2021-01-05 18:32:22

Re: Question about Environment Variables

#17 2021-01-05 21:16:34

Re: Question about Environment Variables

#18 2021-01-06 12:44:01

Re: Question about Environment Variables

#19 2021-01-06 14:36:39

Re: Question about Environment Variables

#20 2021-01-06 15:43:50

Re: Question about Environment Variables

Board footer