Michael wrote: > On Sunday, 26 October 2025 14:05:59 Greenwich Mean Time Dale wrote: >> Alexis wrote: >>> Dale <[email protected]> writes: >>>> Well, those didn't help much directly except to give me some more info >>>> on other things I need to have working correctly. >>> My apologies, i should have been clearer. >>> >>> For others possibly reading this thread in the future, i was trying to >>> say that, if XDG_RUNTIME_DIR isn't getting set: >>> >>> * On a systemd-based system, investigate why logind doesn't seem to >>> be setting it. (E.g. is systemd-logind running?) >>> >>> * On a non-systemd-based system which uses elogind, investigate why >>> elogind doesn't seem to be setting it. (E.g. is elogind-daemon running?) >>> >>> * On a non-systemd-based system which doesn't use elogind, two >>> options are: >>> >>> * Use pam_xdg, although it's not currently in the main repo. >>> >>> * Use the shell snippet described in the "Environment variables" >>> section of the "Configuring a system without elogind" page. >>> >>> >>> Alexis. >> I'm on a openrc system with elogind running. When I was on the boot >> runlevel and on a Console, CTRL ALT F1, it shows the RUNTIME as being >> set. I think it was to /tmp or something. > Normally it would be set to: > > ~ $ env | grep RUNTIME > XDG_RUNTIME_DIR=/run/user/1000 > > where 1000 would be the UID of the current user you login with. > > Now, when I login as my plain user and then run 'su', the environment > variable > remains XDG_RUNTIME_DIR=/run/user/1000. > > However, if I run 'su -', which starts "... a login shell with an environment > similar to a real login" as the man page explains, the XDG_RUNTIME_DIR is > empty. > > As far as I understand it PAM is used to set up the necessary environment if > the user login succeeds. > > Another thing to consider, is encryption. If the user you're trying to login > with has not decrypted their /home, then env variables will not be able to > access the filesystem and errors will be reported. > > When you start, or return at boot runlevel, a lot of services are stopped. >
TLDR: Skip to last part if you want. :-D Although, long version might explain some things. I have a menu item for Konsole. I just set it to run as root under advanced. I'm not real sure how it loads variables. Back in the old KDE4 and before days, I used su - tho. I set that within Konsole's profile. My root file system and /home are not encrypted. I can boot and run my system without the encrypted file systems. When I go to boot runlevel, I also have to kill some programs that should stop when I logout. Pipewire is one of them. There are other KDE related programs that don't stop when I logout too. I use htop to find them and sometimes checkrestart. In the past, if I don't stop, it seems to start a whole new set of those when I login again. That's why I started killing them when I was in boot runlevel. I'm not sure why KDE doesn't stop them when I logout. >> I just saw it set and >> thought the file I added was fixing it. I checked it after restarting >> elogind with the new file and option in place. > You should not need any new pam_*.so file not already installed by portage, > unless you are purposefully modifying PAM. The file /usr/lib64/security/ > pam_elogind.so is called by: > > ~ $ grep -i elogin -r /etc/pam.d/ > /etc/pam.d/sddm-greeter:session required pam_elogind.so > /etc/pam.d/system-login:-session optional pam_elogind.so > > Check the above entries are present in your system. root@Gentoo-1 / # grep -i elogin -r /etc/pam.d/ /etc/pam.d/sddm-greeter:session required pam_elogind.so /etc/pam.d/system-login:-session optional pam_elogind.so root@Gentoo-1 / # Looks the same to me. > >> When I went back to >> default runlevel and logged into KDE, it was no longer set when I >> checked in Konsole. > What user did you login as in konsole? Did you use 'su' to change user? Did > you use sudo - with or without '-E'? > See above. >> It seems something unsets it when I login or during >> the startup of KDE. >> >> You have any idea what could cause elogind not to set this or maybe more >> likely, something unsetting it after elogind is running? I'm thinking >> the last one because it was set until I got logged back in again. > Changing user from the user you login as may not preserve the original user's > shell environment. > > My suggestion to re-emerge packages I thought would have some relevance to > your problem would normally recreate any missing or corrupt files. If that > doesn't help, then some more in depth expert troubleshooting would be > required. I was about to re-emerge the programs and then I had a thought. I clicked on the Konsole entry but I told it to ignore the root part, I didn't type in the password. It opened as dale directly. I then checked the environment to see what it shows. Check this out. dale@Gentoo-1 ~ $ env | grep xdg XDG_CONFIG_DIRS=/home/dale/.config/kdedefaults:/etc/xdg XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1 XDG_MENU_PREFIX=plasma- XDG_SEAT=seat0 XDG_SESSION_TYPE=x11 XDG_CURRENT_DESKTOP=KDE XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_SESSION_CLASS=user XDG_VTNR=7 XDG_SESSION_ID=39 XDG_RUNTIME_DIR=/run/user/1000 XDG_DATA_DIRS=/usr/local/share:/usr/share dale@Gentoo-1 ~ $ And there it is. So, either it was who I was running the command as or at some point during this, it fixed itself. I might add, that large sddm file problem I was having, it is sitting at about 23KBs right now. It's been the same size for a couple days, since I logged in last time. I'm not sure what but I think something I did fixed it. I'm not sure what did it tho. Either way, it appears to be set now. As a bonus, the sddm file is normal again as well. Now I wonder. ;-) Dale :-) :-)
