Hey @palves
As far as I'm aware steam doesn't touch XDG_RUNTIME_DIR. Whatever process is launching steam probably already has the bad environment variable set and steam just inherits it.
E.g. you can try running steam like this: XDG_RUNTIME_DIR=/a/fake/path and then check the value the steam process has via strings /proc/$(pgrep -xo steam)/environ |grep XDG_RUNTIME_DIR. You'll notice that steam didn't change the value provided.
You might want to check with the process that launches steam on your system to see if they have the right values.
Hi @lostgoat ,
Bah, you're right. I don't know why I didn't think of just testing that before reporting the issue. In fact, I've just now spawned Steam from a terminal and it ends up with the right environment... Really sorry for the noise, and thanks for the right nudge.
Closing per the last comment.
Nothing extracted yet.
Your system information
Version 1687386907
Ubuntu 22.04
No
Yes
tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs]AMD
Please describe your issue in as much detail as possible:
I tried adding a flatpak to Steam as a non-steam game, and, it didn't work, the program just wouldn't start. To try to diagnose what is happening, I added my terminal (konsole) program as non-steam game, and launched it. Then, within that terminal, I launched the flatpak with:
$ flatpak run foobar
and I got:
"error: Unable to allocate instance id"
I tried other flatpaks and they all give the same error.
When starting the same flatpaks in the same way from a terminal that wasn't spawned by Steam, they launch fine. So there is something in the environment that Steam creates for its spawned games that is messing up flatpaks.
I looked over the source code of flatpak on github, found where the "Unable to allocate instance id" error is emitted, and noticed that the code around it calls the g_get_user_runtime_dir() glib function, which according to:
https://docs.gtk.org/glib/func.get_user_runtime_dir.html
is associated with the XDG_RUNTIME_DIR environment variable.
Comparing the environment seen by bash under konsole when started outside Steam vs from Steam, I see:
-XDG_RUNTIME_DIR=/run/user/1000 # from steam
+XDG_RUNTIME_DIR=/run/user/1005 # outside steam
Ah! I run Steam and other play stuff on a separate user account from my main account. The account where I installed Steam and where I am running Steam from has user ID 1005. Somehow, Steam spawns the game with the wrong XDG_RUNTIME_DIR path! User 1005 can't access /run/user/1000, hence the error. Maybe Steam hardcodes user ID 1000, as that's the default user ID on single-user GNU/Linux machines?
Doing:
export XDG_RUNTIME_DIR=/run/user/$(id -u)
flatpak run foobar
... "fixed it".
Doing:
$ set | grep 1000, I see that DBUS_SESSION_BUS_ADDRESS has likewise the wrong path pointing to user 1000...
And then doing:
$ grep -a 1000 /proc/$PID_OF_STEAM/environ
I see that XDG_RUNTIME_DIR/DBUS_SESSION_BUS_ADDRESS are already wrong in the Steam process itself... The process itself is owned by 1005 (ls -l /proc/$PID_OF_STEAM confirms it).
Sounds like the issue is in the /usr/bin/steam script or some script that that runs before finally starting the real steam binary?
As a workaround, I can just wrap the lanched game in a small script that fixes XDG_RUNTIME_DIR/DBUS_SESSION_BUS_ADDRESS. But of course, it would be nice not to have to workaround this...