Same problem.
Also "slackware64-current".
I have played on 17 Oct. Today (18 Oct) when I started steam, it downloaded update and installed it. Here is the info from "about"

Steam Beta Branch:  Steam Beta Update
Steam Version:  1792192922
Steam Client Build Date:  Sat, Oct 17, 2026 00:56 UTC +03:00
Steam Web Build Date:  Sat, Oct 17, 2026 02:18 UTC +03:00
Steam API Version:  SteamClient023

steam-runtime-launch-client[13097]: E: Can't find session bus: Failed to execute child process “dbus-launch” (No such file or directory)

This looks as though either you don't have a D-Bus session bus running, or you do but Steam isn't finding it. The new 64-bit beta client requires a working D-Bus session bus, as mentioned in https://github.com/ValveSoftware/steam-for-linux/blob/master/README.beta.md.

What is the value of the DBUS_SESSION_BUS_ADDRESS environment variable in the environment where you ran Steam?

On typical Linux systems it would normally look something like either unix:path=/run/user/1000/bus or unix:path=/tmp/dbus-xRmL89XzNe.

On systems that do not use systemd (which I think includes Slackware?), starting a D-Bus session bus is normally done by either some distro-specific infrastructure (perhaps in /etc/X11/Xsession.d or a similar location, but this varies between distros), or the desktop environment, or by running dbus-launch or dbus-run-session. Please consult Slackware's support channels if you are unsure how the session bus is meant to be started.

Note that the D-Bus system bus (dbus-daemon --system, dbus-monitor --system) is not the same thing as the session bus (dbus-daemon --session, dbus-monitor --session). It's the session bus that Steam needs.

I was able to "workaround" the issue with running

export STEAM_FORCE_CLIENT=ubuntu12_32

before starting steam.
I couldn't investigate further, because I got distracted playing games.

I do have running system-wide dbus, as it's needed for pipewire+bluez, aka bluethooth headphones.
Steam is known to use namespaces, so it's very likely the new runtimes (steamrt64) assume certain locations and fails to copy the relevant files and named sockets. Or rely on systemd to setup them up.

Thank you for looking into this.

What is the value of the DBUS_SESSION_BUS_ADDRESS environment variable in the environment where you ran Steam?

Like I've said, I have a working dbus component servicing whatever it has to service on my system. But there are no DBUS* variables in the environment, and the system-wide communication point for the server is at /run/dbus/system_bus_socket. I don't think I have anything like individual user-scoped communication point similar to the examples you mention below:

    On typical Linux systems it would normally look something like either `unix:path=/run/user/1000/bus` or `unix:path=/tmp/dbus-xRmL89XzNe`.

Now, as I'm on Slackware:

    On systems that do not use systemd

So maybe you could tell me what the new Steam client expects from the system's dbus component, in a bit more detail? The README.md just says 'D-Bus session bus'. I have some dbus stuff running with -session mentioned by process list:

$ ps awwwjx |grep dbus
    1  1283  1283  1283 ?           -1 Ss      81   0:00 /usr/bin/dbus-daemon --system
    1  1587  1582  1582 ?           -1 S     1000   0:00 dbus-launch --autolaunch 87fbf37a60a4f2d3f5152a6d69c4b053 --binary-syntax --close-stderr
    1  1588  1588  1588 ?           -1 Ss    1000   0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
 1792  1798  1588  1588 ?           -1 S     1000   0:02 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/run/user/1000/at-spi/bus_0
    1  9373  9373  9373 ?           -1 Ss    1000   0:00 /usr/bin/dbus-daemon --syslog --fork --print-pid 6 --print-address 8 --session

but I have no ides what to look for in the sense of launching or requesting such dbus stuff on behalf of a user.

4. I was able to "workaround" the issue with running

Oh, capital! Thank you! Won't last long I expect, but perhaps will keep until the more permanent solution arrives.

I do have running system-wide dbus, as it's needed for pipewire+bluez, aka bluethooth headphones.

the system-wide communication point for the server is at /run/dbus/system_bus_socket.

Those are the system bus. Steam needs the session bus, which is not the same.

This is something that your OS distribution or your desktop environment should normally be setting up for you: end users shouldn't usually be expected to set this up themselves (but if you've chosen an OS that is relatively "DIY" then you might have to).

dbus-launch --autolaunch 87fbf37a60a4f2d3f5152a6d69c4b053 --binary-syntax --close-stderr

That is (probably) a session bus, being run by the deprecated "autolaunch" mechanism. What is meant to happen is that the first time dbus-launch gets run, it writes the address of the session bus into an X11 window property on the root window, and then the next time something runs dbus-launch, it reads back the address from that window property.

But, in a well-integrated distribution or desktop environment, autolaunch is not meant to be be necessary. Instead, there should be something that runs when you log in or start a GUI session, which arranges for dbus-daemon to be run with some arguments including --session, and puts its address into the DBUS_SESSION_BUS_ADDRESS environment variable, from which everything else in the GUI session can inherit it. I don't use Slackware, so I don't know how this is meant to look in Slackware, but hopefully there is some component that is responsible for doing this; Slackware support channels would be a likely place to find this information.

From https://www.linuxquestions.org/questions/slackware-14/[idea]-experiments-with-the-session-dbus-daemon-4175767300/ it seems like the Slackware way to do this might involve scripts named /etc/X11/xinit/xinitrc.* that run dbus-launch.

For comparison, the non-systemd code path in Debian is that when you log in to an X11 session, there's some Debian infrastructure that sources shell script snippets from /etc/X11/Xsession.d/, and one of those shell script snippets is https://salsa.debian.org/utopia-team/dbus/-/blob/debian/trixie/debian/75dbus_dbus-launch?ref_type=heads which runs dbus-launch. There is (or used to be) a similar thing in Fedora, but with a different directory, /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh instead of /etc/X11/Xsession.d/75dbus_dbus-launch. Perhaps Slackware has an equivalent?

Steam's requirement here is the same as for any other desktop component that interacts with the session bus, like notification-daemon and xdg-desktop-portal. If there are special steps needed on Slackware to make those components work, then those should also be sufficient to make the updated Steam Client work.

See dbus-launch(1) and dbus-run-session(1) for more information about those.

@kisak-valve, I suggest retitling this to something like "Launching games in beta client requires D-Bus session bus since October 2026" to separate it from anything else that might have regressed in the beta client around the same time.

    This is something that your OS distribution or your desktop environment should normally be setting up for you: end users shouldn't usually be expected to set this up themselves (but if you've chosen an OS that is relatively "DIY" then you might have to).
    > `dbus-launch --autolaunch 87fbf37a60a4f2d3f5152a6d69c4b053 --binary-syntax --close-stderr`

Noted, and thank you, but I'll have to get back to all that tomorrow.

I would appreciate if the title is not changed until the root cause is found.

Slackware does not lack dbus and not having a running dbus-daemon session is not the exact issue here.

The issue is that "Steam runtime environments lack dbus-launch and fails to start anything if DBUS env vars are not already set".

As I suspected, the reason is that Steam restarts in chroot/namespace that hides system programs and uses only it's own "runtime". However that runtime does not have the dbus-launch program that steam binary needs.

This is the first line of the log of this bugreport:

E: Can't find session bus: Failed to execute child process “dbus-launch” (No such file or directory)

In the logs I can see:

ReexecSteamLinux: received re-exec request with code: 67 steamrt: 0
ReexecSteamLinux: re-launching steam in SteamRT runtime

Here are some example from strace log:

12110 execve("/home/iiv3/Steam/steamrt64/pv-runtime/steam-runtime-steamrt/bin/dbus-launch", ["dbus-launch", "--autolaunch=5665e9fa8f8f984e338"..., "--binary-syntax", "--close-stderr"], 0x1779990 /* 60 vars */) = -1 ENOENT (No such file or directory)
12110 execve("/usr/local/bin/dbus-launch", ["dbus-launch", "--autolaunch=5665e9fa8f8f984e338"..., "--binary-syntax", "--close-stderr"], 0x1779990 /* 60 vars */) = -1 ENOENT (No such file or directory)
12110 execve("/usr/bin/dbus-launch", ["dbus-launch", "--autolaunch=5665e9fa8f8f984e338"..., "--binary-syntax", "--close-stderr"], 0x1779990 /* 60 vars */) = 0
[...]
12195 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9e464f5290) = 12210
12210 execve("/usr/bin/dbus-launch", ["dbus-launch", "--autolaunch", "5665e9fa8f8f984e338c5af154888b24", "--binary-syntax", "--close-stderr"], 0x556c07a57ca0 /* 82 vars */) = -1 ENOENT (No such file or directory)
12210 execve("/usr/bin/dbus-launch", ["dbus-launch", "--autolaunch", "5665e9fa8f8f984e338c5af154888b24", "--binary-syntax", "--close-stderr"], 0x556c07a57ca0 /* 82 vars */) = -1 ENOENT (No such file or directory)
12210 execve("/bin/dbus-launch", ["dbus-launch", "--autolaunch", "5665e9fa8f8f984e338c5af154888b24", "--binary-syntax", "--close-stderr"], 0x556c07a57ca0 /* 82 vars */) = -1 ENOENT (No such file or directory)
12210 exit_group(1)    

The first attempt is from the system environment (after two unsuccessful attempt, the 3'd one succeeds).
The second attempt is after the restart, despite trying the exact same path that previously succeeded, this time the file itself is not found.

I have to note that I've been using STEAM_RUNTIME=0 to not have to bother with Steam's self-made "DLL hell", but in this case it doesn't seem to have any effect.

So, the least-effort workaround is to start with
dbus-launch ~/Steam/steam.sh

If you have previously used STEAM_FORCE_CLIENT Steam will remember it and keep using the forced one. To "reset" it try running with this once

export STEAM_FORCE_CLIENT=steamrt64

Slackware does not lack dbus and not having a running dbus-daemon session is not the exact issue here.

Thinking about this more, the root cause for this issue is that Slackware is that relying on X11 autolaunching to start dbus-daemon, and therefore does not have DBUS_SESSION_BUS_ADDRESS in the environment. This means that every time any program needs access to the session bus, it starts a new instance of dbus-launch --autolaunch. Whichever one is the first to start will become "the" session bus, and continue running in the background. The second and subsequent dbus-launch instances will contact the first one, report its address back to their caller and self-destruct.

However, as you said, there is no dbus-launch inside the Steam Client's container, so this doesn't work for the Steam Client's container. It most likely can't work across a container boundary anyway, because the container infrastructure needs to be able to find out the address of the session bus during setup, so that it can share the appropriate socket with the container.

The Steam Client could probably work around this by running dbus-launch outside the container during startup if necessary, and putting the result in DBUS_SESSION_BUS_ADDRESS for the container to inherit.

D-Bus X11 autolaunching is not a good design in general, because dbus-launch and dbus-daemon end up being child processes of a completely arbitrary parent, which means that all D-Bus services will inherit their environment variables, resource limits and other execution environment from that parent, whether that's appropriate or not. This leads to non-deterministic behaviour that will make D-Bus services unreliable. So I would recommend asking the Slackware maintainers of dbus (and/or whatever shared X11 infrastructure exists in Slackware) to arrange for it to be started in a more predictable way during login, leaving DBUS_SESSION_BUS_ADDRESS set and inherited for the entire X11 session, similar to the Debian and Fedora mechanisms that I pointed to in a previous comment. That would make D-Bus in general a lot more robust, not just for Steam but for all programs that interact with it.

that runtime does not have the dbus-launch program

Adding dbus-launch to the Steam Runtime container would not be a good solution to this: if we did that, then D-Bus-activated services unrelated to Steam would try to start up inside the container, and fail.

dbus-launch ~/Steam/steam.sh

Note that this unconditionally starts a new D-Bus session bus in parallel with the one that might already be running or autolaunched. This means that you'll potentially get one copy of each D-Bus service on your original session bus, and a second copy on the new bus that you've started for Steam; if those services try to write to the same file, then whichever one writes second will overwrite any changes made by the first one ("last write wins"). This is rarely what is wanted.

This will also not terminate the new D-Bus session bus after Steam exits.

If you genuinely want a separate, private session bus for Steam, a better way to achieve that would be dbus-run-session -- ~/Steam/steam.sh, which does terminate the new session bus after Steam exits.

when you log in to an X11 session, there's some Debian infrastructure that sources shell script snippets from /etc/X11/Xsession.d/, and one of those shell script snippets is https://salsa.debian.org/utopia-team/dbus/-/blob/debian/trixie/debian/75dbus_dbus-launch?ref_type=heads which runs dbus-launch. There is (or used to be) a similar thing in Fedora, but with a different directory, /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh instead of /etc/X11/Xsession.d/75dbus_dbus-launch. Perhaps Slackware has an equivalent?

It looks as though Slackware packages sddm, which has an Xsession script that sources shell snippets from /etc/X11/Xsession.d, the same directory used in Debian. So the same snippet used in Debian, or something very similar, could be placed in that directory.

However, that's a sddm feature rather than a more general Slackware feature, and I don't know what integration is offered in Slackware as a whole.

What desktop environment (if any) and what display manager (if any) are you using?

the root cause for this issue is that Slackware is that relying on X11 autolaunching to start dbus-daemon, and therefore does not have DBUS_SESSION_BUS_ADDRESS in the environment

A better title for this might be "Can't launch games in beta client if distro relies on D-Bus X11 autolaunching".

I've been able to reproduce what I believe is the same root cause, and improved the container framework to work in that scenario.

@yurytch, @iiv3, please try this:

• Revert any other workarounds
• Download https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/jobs/3443032/artifacts/raw/_build/pressure-vessel-bin.tar.gz (from !1077 v1)
• Unpack it in some convenient location: I usually unpack into ~/tmp, so that I get e.g. ~/tmp/pressure-vessel/bin/
• Run Steam with environment variables PRESSURE_VESSEL_PREFIX=$HOME/tmp/pressure-vessel and STEAM_FORCE_CLIENT=steamrt64

For example if you normally run ~/Steam/steam.sh like @iiv3 does, you could change that to:

env STEAM_FORCE_CLIENT=steamrt64 PRESSURE_VESSEL_PREFIX=$HOME/tmp/pressure-vessel ~/Steam/steam.sh

Please report back whether this is successful: hopefully it will resolve the problem. If successful, we can include the change in a future Steam Client beta update.

I would still recommend that Slackware's OS developers should integrate a D-Bus session bus with a setup similar to the Debian/Fedora script snippets that I mentioned in previous comments, because that would be a general robustness improvement for anything that uses D-Bus; but with the change I've proposed, that would no longer be critical-path for starting Steam.

@smcv, @iiv3: A pleasure to see masters at work, thank you guys. The test solution by @smcv seems to work (likewise @iiv3's workaround), and I'll definitely have a look at what @smcv suggests w/r to better dbus integration.

I've been able to reproduce what I believe is the same root cause, and improved the container framework to work in that scenario.
* Download https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/jobs/3443032/artifacts/raw/_build/pressure-vessel-bin.tar.gz (from !1077 v1)

env STEAM_FORCE_CLIENT=steamrt64 PRESSURE_VESSEL_PREFIX=$HOME/tmp/pressure-vessel ~/Steam/steam.sh

+1ing this solution from @smcv

Just rebooted and relaunched Steam, so just got caught with this update and ended up here. Using this build smcv posted got it working again.

me:

Steam Beta Branch:  Steam Beta Update
Steam Version:  1792192922
Steam Client Build Date:  Fri, Oct 16, 2026 13:56 UTC -08:00
Steam Web Build Date:  Fri, Oct 16, 2026 15:18 UTC -08:00
Steam API Version:  SteamClient023

DE: none
WM: awesome v4.3 (Too long)
OS: Artix Linux

I start x via startx and have exec awesome tailing my .xinitrc.

got caught with this update and ended up here. Using this build smcv posted got it working again

If this worked for you, then your OS or personal configuration must be relying on X11 autolaunching, rather than something that is properly integrated into the OS or desktop environment. X11 autolaunching is a bad design, for the reasons I mentioned in previous comments, and I would recommend avoiding it.

I […] have exec awesome [at the end of] my .xinitrc

If you put code similar to https://src.fedoraproject.org/rpms/dbus/blob/f45/f/00-start-message-bus.sh earlier in your .xinitrc, that would probably have solved this problem for you. But this isn't something that you should need to do yourself, it's something that a well-integrated OS should automatically do for you (like Debian and Fedora do).

I would recommend that affected OSs' developers should integrate a D-Bus session bus with a setup similar to the Debian/Fedora script snippets that I mentioned, because that would be a general robustness improvement for anything that uses D-Bus. Please contact your OS vendor's support channels to find out how D-Bus is meant to work in this OS and how it can be taught to integrate it better.

If you put code similar to https://src.fedoraproject.org/rpms/dbus/blob/f45/f/00-start-message-bus.sh earlier in your .xinitrc

I did see that as a solution otw to this thread actually, but like isn't it kinda pointless if this IPC middleman only has one process trying to communicate on it? If steam is failing to start because it assumes its there, isn't that kinda telling about who all is using it on our systems?

it's something that a well-integrated OS should automatically do for you (like Debian and Fedora do).
I would recommend that affected OSs' developers should integrate a D-Bus session bus with a setup similar to the Debian/Fedora script snippets that I mentioned, because that would be a general robustness improvement for anything that uses D-Bus. Please contact your OS vendor's support channels to find out how D-Bus is meant to work in this OS and how it can be taught to integrate it better.

This really makes me not want it lol. Doing something more like RHEL has got to be the worst pitches imaginable for me.

Going forwards ya think steam is gonna assert a session-wide dbus to exist? I guess I could write an alias to use that dbus-run-session -- steam ya mentioned before if so

Well, @Lightsockie raises a good point there.
I admit my great ignorance in the matter, but while big combines like KDE or Gnome might actually require something like Dbus, why would a game launcher, basically a Chrome browser, which isn't integrated (?) into any of those? What does it achieve by connecting to Dbus?

isn't it kinda pointless if this IPC middleman only has one process trying to communicate on it? If steam is failing to start because it assumes its there, isn't that kinda telling about who all is using it on our systems?

It's very likely that you do have other processes communicating on the D-Bus session bus. The bug here is that if you are relying on D-Bus X11 autolaunching (one of several possible mechanisms) to start and discover the session bus, then Steam's container framework is currently unable to detect and use it. This is what's fixed in https://github.com/ValveSoftware/steam-for-linux/issues/13767#issuecomment-6293822698, and that change is likely to be integrated in a future beta.

D-Bus X11 autolaunching is a problematic mechanism that can easily lead to very strange bugs: it was necessary when D-Bus was a new and non-standard thing that wasn't integrated into OS distributions, but that was 20+ years ago! Starting a D-Bus session bus at the beginning of your X11 session will lead to a more reliable overall system and I would recommend it.

why would a game launcher, basically a Chrome browser, which isn't integrated (?) into any of those? What does it achieve by connecting to Dbus?

A game launcher is not just a user interface, it also launches games. The D-Bus session bus is used for communication between parts that run inside a container, and parts that need to run outside a container.

And, yes, Steam is integrated with desktop environment mechanisms that use D-Bus: for example it uses xdg-desktop-portal for file/directory opening dialogs and to open URLs in the system web browser.

I guess I could write an alias to use that dbus-run-session -- steam ya mentioned before if so

This workaround is not a good long-term solution. If you do this, it will always start a new D-Bus session bus, even if you already had one running. This can lead to each D-Bus session service being started twice (once for your ordinary session bus, and once for the new session bus you started for Steam), and if both copies try to write to the same file, they'll overwrite each other's changes.

     A game launcher is not just a user interface, it also launches games. The D-Bus session bus is used for communication between parts that run inside a container, and parts that need to run outside a container.

Very well, is there some test (script or whatever) to check if the system complies with what the launcher wants from its Dbus component?

@yurytch, @iiv3, please try this:
* Revert any other workarounds
* Download https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/jobs/3443032/artifacts/raw/_build/pressure-vessel-bin.tar.gz (from !1077 v1)
* Unpack it in some convenient location: I usually unpack into ~/tmp, so that I get e.g. ~/tmp/pressure-vessel/bin/
* Run Steam with environment variables PRESSURE_VESSEL_PREFIX=$HOME/tmp/pressure-vessel and STEAM_FORCE_CLIENT=steamrt64

@smcv
This seems to work fine.