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. > 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. > 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'? > 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.
signature.asc
Description: This is a digitally signed message part.
