PATH is not update from ~/.pam_environment for systemd user service

admich · 2019-10-05 07:08:47

I want to change PATH for systemd user service (I'm interested in emacs service).

I have put the new definition for PATH in ~/.pam_environment like this:
PATH DEFAULT=/usr/local/bin:/usr/bin:/home/myhome/bin OVERRIDE=/usr/local/bin:/usr/bin:/home/myhome/bin

but the PATH remains (checked with systemctl --user show-environment):

/usr/local/bin:/usr/bin

The other variables defined in defined in ~/.pam_environment are update but PATH no.
Also the PATH is not update only for systemd service. Bash, and all applications that I start after the login have the updated PATH.

brainplot · 2019-12-24 01:40:11

I'm having the same exact issue with the same exact service. Did you figure it out?

admich · 2019-12-24 08:29:17

No, I don't resolve the problem and I didn't receive any answers to my question. For the moment I use a workaroud: I set the PATH environment variable in the emacs init file, with setenv elisp function. Of course this is not ideal because I need to mantain my PATH in two different location: the emacs init file and in ~/.pam_environment .

seth · 2019-12-24 08:56:21

https://wiki.archlinux.org/index.php/Sy … _variables

brainplot · 2019-12-24 12:32:31

Seth, I don't think that's the issue. I have all of my user environment variables set in ~/.pam_environment and they're all inherited by the emacs service, which starts at boot and I enabled with `systemctrl --user enable emacs.service` - except for $PATH.
Not sure why only $PATH is affected. All other programs I launch (or even my shell) in my user session correctly inherit my variables from my ~/.pam_environment, including $PATH.

One other thing to note is that if I restart the emacs.service after I've logged in, with `systemctrl --user restart emacs.service`, the service picks everything up as it should. I don't think `systemctrl --user` when it first starts a service runs in a different environment than when it starts a service after logging in, does it? Even if it did, the fact that only $PATH is the variable not inherited is very strange.

Lone_Wolf · 2019-12-24 13:36:35

Sounds like something executed after ~/.pam_environment is sourced overwrites $PATH .

temporarily disable emacs.service at boot .
login , verify your environment .
start emacs user service, check environment .

Does it now have the correct $PATH ?

seth · 2019-12-24 13:42:54

All other programs I launch (or even my shell) in my user session correctly inherit my variables from my ~/.pam_environment, including $PATH.
…
One other thing to note is that if I restart the emacs.service after I've logged in, with `systemctrl --user restart emacs.service`, the service picks everything up as it should.

pam_env gets overridden but some other shell (bashrc) "sanitizes" it?

The OP suggested that "systemctl --user show-environment" prints the "wrong" $PATH - does that hold for you as well?

brainplot · 2019-12-24 14:17:56

`systemctl --user show-environment` prints the correct $PATH. I tried disabling the emacs.service so that it doesn't start automatically at boot. I then restarted my machine and once I logged in, I ran `systemctrl --user start emacs.service` and then checked that the service started with `systemctrl --user status emacs.service`; everything was up and running. I then opened the emacsclient to check my $PATH and it was indeed correct, with my additions from `~/.pam_environment` that is.

There must be something about enabling the emacs.service at boot that prevents it from inheriting my custom $PATH.
Unfortunately, that's the only user service I have enabled. What service could I use to test this with something else that's not Emacs? The fact that both OP and I are facing this problem with the emacs service makes me suspicious.

Last edited by brainplot (2019-12-24 14:18:30)

seth · 2019-12-24 14:21:03

So it's different from the OP - how do you infer the wrong $PATH? Sounds like from within emacs?
What about

tr '\0' '\n' < /proc/$(pidof emacs)/environ

?

(nb. I'm not sure about the emacs binary name/structure, the pidof might be wrong, please substitute the actual PID)

brainplot · 2019-12-24 15:06:26

It inherits everything from my `~/.pam_environment` except for $PATH:

$ tr '\0' '\n' < /proc/(pidof emacs)/environ
ALTERNATE_EDITOR=emacs
ANDROID_SDK_ROOT=/home/brainplot/Android/Sdk
CARGO_HOME=/home/brainplot/.local/opt/cargo
CMAKE_BUILD_PARALLEL_LEVEL=8
COMPOSER_HOME=/home/brainplot/.local/opt/composer
CTEST_PARALLEL_LEVEL=8
EDITOR=emacsclient -t
ELECTRON_TRASH=kioclient5
GTK_USE_PORTAL=1
HOME=/home/brainplot
LANG=en_US.UTF-8
LOGNAME=brainplot
MAIL=/var/spool/mail/brainplot
PATH=/usr/local/bin:/usr/bin
SHELL=/usr/bin/fish
USER=brainplot
VISUAL=emacsclient -c
XDG_RUNTIME_DIR=/run/user/1000
npm_config_prefix=/home/brainplot/.node_modules
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MANAGERPID=596
INVOCATION_ID=8f42dd1862ea494aa576c6ae45ec9bed
JOURNAL_STREAM=9:23789
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

I'm using Fish, that's why it's `(pidof emacs)` without the dollar sign.

seth wrote:

how do you infer the wrong $PATH? Sounds like from within emacs?

Yes, I can verify my $PATH from within emacs by trying to run a shell command in it: it fails to tab-complete binaries that reside in any of the locations I added to $PATH; or by opening eshell within emacs and running `echo $PATH` (it prints "/usr/local/bin:/usr/bin").

However, as I was mentioning in my previous posts, if I restart the emacs.service with `systemctrl --user restart emacs.service` after I've logged in, I can see my custom $PATH in `/proc/(pidof emacs)/environ` (checked with the command you suggested).
Emacs also tab-completes my binaries just fine and eshell prints the correct value of $PATH.

For reference, this is my `~/.pam_environment`:

$ cat ~/.pam_environment
# NodeJS path for global packages (i.e. those installed with `-g`)
npm_config_prefix               DEFAULT=@{HOME}/.node_modules
PATH                            DEFAULT=${npm_config_prefix}/bin:${PATH}

# Set cargo location
CARGO_HOME                      DEFAULT=@{HOME}/.local/opt/cargo
PATH                            DEFAULT=${CARGO_HOME}/bin:${PATH}

# Set up composer installation
COMPOSER_HOME                   DEFAULT=@{HOME}/.local/opt/composer
PATH                            DEFAULT=${COMPOSER_HOME}/vendor/bin:${PATH}

# Use KDE file picker in GTK apps
GTK_USE_PORTAL                  DEFAULT=1

# Set the default number of jobs used by `cmake --build` and `ctest`
CMAKE_BUILD_PARALLEL_LEVEL      DEFAULT=8
CTEST_PARALLEL_LEVEL            DEFAULT=${CMAKE_BUILD_PARALLEL_LEVEL}

# Enable trash support in KDE for Electron apps
ELECTRON_TRASH                  DEFAULT=kioclient5

# Set the root of the Android SDK for proper detection in Android Studio
ANDROID_SDK_ROOT                DEFAULT=@{HOME}/Android/Sdk
PATH                            DEFAULT=${ANDROID_SDK_ROOT}/platform-tools:${PATH}

# Set user-wide paths to binaries and dynamically-linked libraries
PATH                            DEFAULT=@{HOME}/.local/bin:${PATH}

# System's editors
ALTERNATE_EDITOR                DEFAULT=emacs
EDITOR                          DEFAULT="emacsclient -t"
VISUAL                          DEFAULT="emacsclient -c"

Last edited by brainplot (2019-12-24 15:08:35)

seth · 2019-12-24 15:22:20

I'm using Fish

Wild guess: what if you change your login shell to bash? You didn't alter the /bin/sh resolution, did you?

brainplot · 2019-12-24 16:37:23

seth wrote:

You didn't alter the /bin/sh resolution, did you?

Yes, I did. I installed the dashbinsh package from the AUR. I uninstalled it with `yay -Rsn dashbinsh` and then reinstalled bash with `pacman -S bash` to make sure the symlink was reset, which I checked with `ls -l /bin/sh`.
I also changed my login shell to bash with `chsh -s /bin/bash` but after rebooting the machine nothing changed. The problem persists.

P.S. Before rebooting I also removed the old `~/.bashrc` I had left there, from before I switched to Fish. After the reboot I had a pristine Bash configuration when I opened my terminal. Still, nothing changed in regard to my problem.

Last edited by brainplot (2019-12-24 16:37:55)

Arch Linux

#1 2019-10-05 07:08:47

PATH is not update from ~/.pam_environment for systemd user service

#2 2019-12-24 01:40:11

Re: PATH is not update from ~/.pam_environment for systemd user service

#3 2019-12-24 08:29:17

Re: PATH is not update from ~/.pam_environment for systemd user service

#4 2019-12-24 08:56:21

Re: PATH is not update from ~/.pam_environment for systemd user service

#5 2019-12-24 12:32:31

Re: PATH is not update from ~/.pam_environment for systemd user service

#6 2019-12-24 13:36:35

Re: PATH is not update from ~/.pam_environment for systemd user service

#7 2019-12-24 13:42:54

Re: PATH is not update from ~/.pam_environment for systemd user service

#8 2019-12-24 14:17:56

Re: PATH is not update from ~/.pam_environment for systemd user service

#9 2019-12-24 14:21:03

Re: PATH is not update from ~/.pam_environment for systemd user service

#10 2019-12-24 15:06:26

Re: PATH is not update from ~/.pam_environment for systemd user service

#11 2019-12-24 15:22:20

Re: PATH is not update from ~/.pam_environment for systemd user service

#12 2019-12-24 16:37:23

Re: PATH is not update from ~/.pam_environment for systemd user service

Board footer