This forum has been archived. All content is frozen. Please use KDE Discuss instead.

XDG_RUNTIME_DIR not set automatically

Tags: None
(comma "," separated)
workoft
Registered Member
Posts
97
Karma
1
Hi,

I've been having this problem since I am using Plasma 5, but I never really bothered to fix it, since there is an easy workaround.
Whenever I update Plasma, the session exits again and returns me to the login screen. This can be fixed by adding
XDG_RUNTIME_DIR=/var/run/user/$UID
to the beginning of /usr/bin/startkde
I am using Gentoo Linux and systemd. Just upgraded to Plasma 5.5, but as mentioned, I have had this problem with every version of plasma so far.
The reason I am trying to fix this is because I had the same problem when logging in to a wayland session. Adding the same line to /usr/bin/startplasmacompositor just got me a plasma loading screen instead of the plasma desktop I wanted. I don't know if this has anything to do with it, I just want to solve the other problem before I attempt fixing this one.

Regards,
Malte
mgraesslin
KDE Developer
Posts
572
Karma
7
OS
It's not something Plasma can fix. This XDG_RUNTIME_DIR should be exported and set by the login system. I don't know the details on how it works, but my understanding was that pam_systemd sets it. See http://www.freedesktop.org/software/sys ... stemd.html
vootey
Registered Member
Posts
54
Karma
0
OS
Just FYI: I'm also running gentoo with systemd, Plasma 5.5. And my XDG_RUNTIME_DIR seems to be just set (without any manual massaging of starting scripts).
workoft
Registered Member
Posts
97
Karma
1
Thanks for the prompt replies
vootey wrote:Just FYI: I'm also running gentoo with systemd, Plasma 5.5. And my XDG_RUNTIME_DIR seems to be just set (without any manual massaging of starting scripts).

I can't really find any useful information on a fix. What login manager are you using? And how is pam_systemd.so listed in /etc/pam.d/
I am using sddm and grep pam_systemd /etc/pam.d/* returns
/etc/pam.d/sddm-greeter:session optional pam_systemd.so
/etc/pam.d/system-auth:-session optional pam_systemd.so
vootey
Registered Member
Posts
54
Karma
0
OS
workoft wrote:What login manager are you using?

sddm (v0.13.0-r1) as well
workoft wrote:And how is pam_systemd.so listed in /etc/pam.d/
I am using sddm and grep pam_systemd /etc/pam.d/* returns
/etc/pam.d/sddm-greeter:session optional pam_systemd.so
/etc/pam.d/system-auth:-session optional pam_systemd.so

Exactly the same here.
luebking
Karma
0
Sure it's unset and doesn't just point to /run/user/$UID (systemd/logind default) and you just don't follow the systemd "requirement" where /var/run "has to be" a symlink to ../run (but you eg. have no /run)
workoft
Registered Member
Posts
97
Karma
1
luebking wrote:Sure it's unset and doesn't just point to /run/user/$UID (systemd/logind default) and you just don't follow the systemd "requirement" where /var/run "has to be" a symlink to ../run (but you eg. have no /run)

By default XDG_RUNTIME_DIR points to /tmp. /var/run is a symlink to /run and /run exists.
luebking
Karma
0
Whatever sets XDG_RUNTIME_DIR to /tmp (and /tmp only?) is the culprit since this will cause collisions (it's supposed to be UID uinique)
Sustituting /tmp w/ $XDG_RUNTIME_DIR is ok (and suggested) but turning XDG_RUNTIME_DIR into /tmp is a very bad idea.
workoft
Registered Member
Posts
97
Karma
1
Thanks, this got me on the right track! It turns out, I was looking for the solution in all the wrong places. XDG_RUNTIME_DIR wasn't not set properly, it was re-set improperly, using a file in /etc/env.d. It may have even been me who put it there, for whatever reason. Which is kind of embarassing. :| Thanks everyone for helping.


Bookmarks



Who is online

Registered users: Bing [Bot], Evergrowing, Google [Bot]