SteamVR can't launch due to missing dbus-launch executable

[PureTryOut]

Game information
SteamVR

Distribution name and version where applicable
Alpine Linux edge

Flatpak info
1.8.2

> flatpak --gl-drivers
default
host

Problem description

Whenever I try to launch SteamVR I get the following message:

Failed to connect to session bus: Failed to execute child process “dbus-launch” (No such file or directory)

Does this issue reproduce with native Steam
I can't test this but I doubt it, you can just install the dbus-launch package to make it work.

[gasinvein]

Just guessing: SteamVR actually don't need dbus-launch, it tries to launch dbus because it didn't find session bus socket. Is dbus session instance running on your host? If not, try running the whole Steam flatpak via dbus-launch.

[PureTryOut]

Well dbus is running yes, that's done by KDE Plasma. However if I do launch the flatpak with dbus-launch, it acts differently. The aforementioned error isn't happening anymore, but now I get a window that asks me how to open x-scheme-handler/steam.

I would assume I have to choose Steam there, but doing so doesn't make it open SteamVR, it just closes that window. The log doesn't tell me anything useful there.

[gasinvein]

Something doesn't seem right on your side. If KDE launches DBus session instance indeed, flatpak doesn't detect it and thus doesn't spawn dbus proxy for the sandbox. Check if the session bus socket is present at $XDG_RUNTIME_DIR/bus or set in the $DBUS_SESSION_BUS_ADDRESS env var.

[PureTryOut]

I don't have $XDG_RUNTIME_DIR/bus, but I do have $XDG_RUNTIME_DIR/dbus-1 which contains an empty services folder.

$DBUS_SESSION_BUS_ADDRESS is empty for me.

[gasinvein]

Then I don't know where the socket might be (neither does flatpak, I guess). Are you sure session bus is actually launched?

[PureTryOut]

Well the dbus-daemon is running (I see it in htop), but I don't know how else to check.

A quick internet search leads me to this Stackoverflow post which suggests dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames as a way of seeing what D-Bus services are running. It gives me quite a few services as a result so I'm pretty sure D-Bus is running perfectly fine.

[gasinvein]

You should have at least two dbus-daemon processes running - one as root for the system bus, and one as your user for the session bus.

[PureTryOut]

> ps aux | grep /usr/bin/dbus-daemon
bart      1388  0.0  0.0   1452   860 pts/2    S+   18:44   0:00 grep --color=auto /usr/bin/dbus-daemon
root      3515  0.0  0.0    920   472 ?        S    17:30   0:00 supervise-daemon dbus --start /usr/bin/dbus-daemon -- --system --nofork
message+  3516  0.0  0.0   2292  2024 ?        Ss   17:30   0:00 /usr/bin/dbus-daemon --system --nofork
bart      3889  0.1  0.0   2316  1664 ?        Ss   17:30   0:04 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
bart      8996  0.0  0.0   1420  1160 ?        S    17:55   0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
bart      9140  0.0  0.0   1644  1068 ?        Ss   17:55   0:00 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
bart      9171  0.0  0.0   1476  1264 ?        S    17:55   0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3

Seems it's running fine.

[gasinvein]

Is it there right after a clean reboot/relogin?

[PureTryOut]

Yes it is, this is just after a reboot without any other applications open (just the Plasma session):

> ps aux | grep /usr/bin/dbus-daemon
root      3515  0.0  0.0    920   528 ?        S    19:01   0:00 supervise-daemon dbus --start /usr/bin/dbus-daemon -- --system --nofork
message+  3516  0.6  0.0   2160  1788 ?        Ss   19:01   0:00 /usr/bin/dbus-daemon --system --nofork
bart      3885  0.8  0.0   2092  1528 ?        Ss   19:01   0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
bart      5205  0.0  0.0   1512   916 pts/0    S+   19:01   0:00 grep --color=auto /usr/bin/dbus-daemon

[nanonyme]

@valentindavid was it so you had some VR equipment? Is it still working for you?

[gasinvein]

@PureTryOut I wonder what does launch dbus for you and why it doesn't set DBUS_SESSION_BUS_ADDRESS var.

[PureTryOut]

Well I'm guessing the KDE Plasma session somewhere in it's booting process. It uses D-Bus to talk to it's own services and stuff too.

[PureTryOut]

Can I get some more help on this? It sadly still doesn't work.

[nanonyme]

Try running flatpak with --log-session-bus and/or --log-system-bus to try to get a better idea what it's trying to do.

[PureTryOut]

steam-flatpak.log

That's with the mentioned arguments. Interestingly enough I didn't need to run the Flatpak command with dbus-launch to get the window as mentioned in #636 (comment) this time, I got it without that as well.

[PureTryOut]

Well, for some reason I don't experience this issue anymore, no clue what changed.

I have an other issue though, I know how to resolve it locally but it would be nice to get this working out-of-the-box. When I launch SteamVR for the first time Zenity pops up.

If I tell it yes, it can proceed, it errors:

Checking that log reveals it's trying to set some required capabilities on the steamvr-launcher binary but fails to do so (probably because of trying to use sudo running inside Flatpak). I can fix this from my host system:

sudo setcap CAP_SYS_NICE+ep ~/.var/app/com.valvesoftware.Steam/data/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher

After this, SteamVR launches successfully. I can't test actually playing games as I'm experiencing this bug which makes my headset completely useless on Linux, but at least it's running.

Should I file a separate issue for this?

[PureTryOut]

Since my original issue is gone, I'm splitting off the SteamVR setup issue to #898 and closing this one. Thanks for the help guys!