Namespaces error when starting Steam with Feral GameMode LD_PRELOAD module
Fromstream opened this issue · comments
Your system information
- Steam client version (build number or date): 1709846872, Mar 6 2024
- Distribution (e.g. Ubuntu): Ubuntu 22.04
- Opted into Steam client beta?: No
- Have you checked for system updates?: Yes
- Steam Logs:
steam-logs.tar.gz - GPU: Intel
Please describe your issue in as much detail as possible:
@smcv : as you required, I open a dedicated issue, even if I think it's really close to the ValveSoftware/steam-for-linux#10617, and related to Lutris.
Since last Lutris (or Steam ?) update, I can't launch any steam game from Lutris. I have the fatal error message from Lutris: "Steam on Linux now requires the ability to create new user namespaces. [...}"
But I can still run the linux steam client directly without this issue.
As mentionned, I found a workaround seting the setuid on bwrap : sudo chmod u+s /usr/bin/bwrap
I will search if I have any Flatpack program to compare to, but since this is a little bit redundant with the Ubuntu snap store, I don't get use to it.
Here's a part of the Lutris logs, if it can help :
"steam-runtime-check-requirements[14974]: E: Cannot run /home/vivien/.steam/ubuntu12_32/steam-runtime/amd64/usr/libexec/steam-runtime-tools-0/srt-bwrap: wait status 134
steam-runtime-check-requirements[14974]: E: Diagnostic output:
dbus[14985]: arguments to dbus_pending_call_block() were incorrect, assertion "pending != NULL" failed in file ../../../dbus/dbus-pending-call.c line 765.
This is normally a bug in some application using the D-Bus library."
Thanks for your help.
Steps for reproducing this issue:
- Run Lutris
- Start a steam game
Hi there, I was facing the same problem on Ubuntu 23.10 and I am unable to reproduce the issue even after using Lutris in general, enabling Lutris runtime or using additional parameters for steam as before, I had launched steam from terminal 2 days ago and it started unpacking the steam runtime and it worked fine since then as before and I had not updated or changed my system in any way. So, I am not aware about the reason that caused the issue in the first place or what fixed it, maybe you can manually try to reset steam linux runtime but Lutris is not interfering with steam for me(anymore).
steam-runtime-check-requirements[14974]: E: Cannot run /home/vivien/.steam/ubuntu12_32/steam-runtime/amd64/usr/libexec/steam-runtime-tools-0/srt-bwrap: wait status 134 steam-runtime-check-requirements[14974]: E: Diagnostic output: dbus[14985]: arguments to dbus_pending_call_block() were incorrect, assertion "pending != NULL" failed in file ../../../dbus/dbus-pending-call.c line 765. This is normally a bug in some application using the D-Bus library.
This is strange. srt-bwrap is part of the Steam Linux Runtime container framework, and it's a very small program that isn't linked to libdbus, so it doesn't make much sense for it to be producing error messages that are characteristically from libdbus.
When Lutris runs Steam, does it perhaps inject arbitrary code in a LD_PRELOAD module that does depend on libdbus? Or is there perhaps some other code getting injected into Steam, perhaps something to do with Gamemode or MangoHUD or some other similar module?
The assertion failure you quoted means that some module (perhaps injected by Lutris, or perhaps something else) is using libdbus, but not checking for errors properly. That would be something to fix in whatever the other module is.
As mentionned, I found a workaround seting the setuid on bwrap : sudo chmod u+s /usr/bin/bwrap
If my theory about LD_PRELOAD is correct, then this is working around the problem accidentally, because setuid executables don't load LD_PRELOAD modules for security reasons.
I'm actually surprised this works, because #650 isn't fixed yet (and that prevents me from using a setuid bwrap successfully on my test system), but perhaps you were lucky...
I couldn't reproduce this with default Lutris settings (freshly-installed Lutris, not previously used) on Ubuntu 22.04.
For reference, the default settings I see are:
Settings in Steam -> cogwheel icon -> Runner options:
- Stop Steam after game exits: OFF
- Start Steam in Big Picture mode: OFF
- Start Steam with LSI: OFF
Settings in Steam -> cogwheel icon -> System options:
- Default installation folder: /home/me/Games
- Disable Lutris Runtime: ON
- Prefer system libraries: ON
- Restore resolution on game exit: OFF
- Disable screen saver: ON
- FPS counter (MangoHud): Disabled (default)
- Enable Feral GameMode: ON
- Enable NVIDIA Prime Render Offload: OFF
- Switch resolution to: Keep current (default)
I can still run the linux steam client directly without this issue
Recommended workaround: do that.
It seems that whatever setup you are using in Lutris is introducing some sort of special configuration that is breaking srt-bwrap.
@Fromstream, here is something that would be useful for diagnosing this:
- Launch Steam in whatever way it is that doesn't work for you. Wait for the error message about user namespaces to appear. Don't close it yet.
- With the error message still open, look at Lutris's logs or terminal output to find the process ID of
steam.sh. For example if you seesteam.sh[1234]: Running Steam on ubuntu 22.04 64-bitthen the process ID is 1234. perl -pe 's/\0/\n/g' < /proc/1234/environ | LC_ALL=C sort -u > environ.txt, replacing 1234 with the correct process ID- Either attach all of
environ.txthere, or look for the lines starting withLD_orSYSTEM_and paste just those lines here.
I think this might be a case of the diagnostic tool steam-runtime-check-requirements being inconsistent with the actual container runtime framework, and as a result, being over-cautious about detecting a problem scenario that will not actually happen. The actual container runtime framework deletes LD_PRELOAD from the environment before starting the container, and then puts it back for a subset of the processes inside the container.
If that's the case, then I can see a path to a solution. Before continuing, I'll need either the results of #658 (comment) from someone who can reproduce this issue, or more complete steps to reproduce the issue myself.
Hi @smcv. First, Many thanks for your time on this issue, while this is not a big one, since there is a simple workaround: launching steam client outside Lutris. Anyway it's an interesting challenge, isn't it? :-)
I'm not so sure as you are that I was "lucky" with the setuid on bwrap, since I can clearly produce the behavior each time:
sudo chmod u+s /usr/bin/bwrap => working
sudo chmod u+s /usr/bin/bwrap => issue
Here is the only line that fit what your criterias on the environ.txt:
LD_PRELOAD=libgamemodeauto.so.0
Regarding the Lutris settings, I have pretty much the same as yours, except I don't have the "Stop Steam after game exits" one, and my "Restore resolution on game exit" is ON. But I don't think this is linked. Anyway I then checked my Lutris version and it seems pretty much outdated : 0.5.12. I thought there was an automatic update with Ubuntu packages, but it seems not. And there was some changes about Steam integration in last releases.
But before trying to update my Lutris, and therefore change conditions to reproduce the issue, please let me first know about your LD_PRELOAD assumption, and how I can verify your theory.
One more thing: in the Luris logs, there is also an error about bwrap iself, not only the srt-bwrap, and it looks similar:
"steam-runtime-check-requirements[15796]: E: Cannot run /usr/bin/bwrap: wait status 134
steam-runtime-check-requirements[15796]: E: Diagnostic output:
dbus[15800]: arguments to dbus_pending_call_block() were incorrect, assertion "pending != NULL" failed in file ../../../dbus/dbus-pending-call.c line 765."
I don't if this can help.
Many thanks again!
@smcv @Fromstream I faced this issue again today when launching another steam game from Lutris and I can confirm, enabling the Feral game mode option in Lutris config recreates this issue, disabling it fixes the issue. I can run all games normally by just disabling feral game mode. I'll leave a screenshot with my current configuration that works normally.
One more thing: in the Luris logs, there is also an error about bwrap iself, not only the srt-bwrap, and it looks similar
The situation is the same for both. bwrap and srt-bwrap are both compiled from (potentially different versions of) the same code, and neither has a libdbus dependency, so the only reason they should be logging libdbus error messages is if something has injected a libdbus-dependent LD_PRELOAD module into them.
I can confirm, enabling the Feral game mode option in Lutris config recreates this issue
OK, this looks fairly conclusive. I'm guessing that enabling or disabling that option sets or unsets LD_PRELOAD=libgamemodeauto.so.0, and that's exactly the sort of module that might be using libdbus.
I think the assertion failure is probably FeralInteractive/gamemode#347.
A minimal reproducer on Ubuntu 22.04 is:
sudo apt install gamemode gamemode-daemon libgamemodeauto0
gamemoderun ~/.steam/root/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-check-requirements
gamemoderun steam also reproduces this issue.
A fix for the diagnostic tool is queued for inclusion in a future Steam release. With that change, the message about failing to create user namespaces doesn't appear, and Steam will start successfully - but I'm still seeing a lot of other crashes with the same message, where lsof is crashing repeatedly during exit.
Until you have a version of gamemode where FeralInteractive/gamemode#467 has been fixed, I would not recommend enabling gamemode for all of Steam. You can enable it for individual games (for example by setting their launch options to gamemoderun %command%) if it makes a measurable difference.
@EliteSkull7 You are absolutly right! When I disabled the Feral GameMode, it worked! Therefore I changed the default configuration for this parameter to be off. Thanks for the tip !
@kisak-valve, please could you retitle this to "Namespaces error when starting Steam with Feral GameMode LD_PRELOAD module" to reflect our current understanding of the problem?
(Lutris makes it more convenient to set up the broken situation, but is not actually required.)
A fix for the diagnostic tool is queued for inclusion in a future Steam release. With that change, the message about failing to create user namespaces doesn't appear, and Steam will start successfully
This change has now reached the Steam public beta, and should eventually land in the general-availability branch too (I don't control that timetable and can't predict when this will happen).
but I'm still seeing a lot of other crashes with the same message, where
lsofis crashing repeatedly during exit. Until you have a version of gamemode where FeralInteractive/gamemode#467 has been fixed, I would not recommend enabling gamemode for all of Steam. You can enable it for individual games (for example by setting their launch options togamemoderun %command%) if it makes a measurable difference.
All of this is still true. I'm not intending to make any further changes within the Steam Runtime or Steam's diagnostic tools for this issue: it seems to be a gamemode problem (the root cause is probably FeralInteractive/gamemode#347), and should be fixed in gamemode.
Just adding this here in case this helps someone or is related to the issue. When I was testing a gamemode update on Solus I noticed that it wasn't working at all with Proton (IE, setting a game to use gamemoderun %command% as the launch arguments). It seems that there are two probably independent issues here:
libgamemodeauto.so.0seems to also needlibgamemode.so.0in the environment but this dependency doesn't show up withldd /path/to/libgamemodeauto.so.0.gamemoderunonly adds the former toLD_PRELOAD, so pressure-vessel doesn't know to pull the other into the environment. I fixed this by patching gamemoderun to add both libs toLD_PRELOAD. This might also be a Solus build issue, but it seems more likely to be a gamemode issue since I noticed a few Arch users with the same complaint.- Even once that change was made I still wasn't seeing the libs get injected into the proton environment. I'm still not sure what the root cause of this is but I was able to get it working by the libs to
/usr/lib64/gamemode/and/usr/lib32/gamemode/and adding the below ldconfig snippet to the package. This is what I hoped the MR adding Solus-style libdir to pressure-vessel would address but it didn't.
/usr/lib32/gamemode
/usr/lib64/gamemode
Just adding this here in case this helps someone or is related to the issue. When I was testing a gamemode update on Solus I noticed that it wasn't working at all with Proton
Please report this to https://github.com/ValveSoftware/steam-runtime/issues as a separate issue, it's out-of-scope for this one. This issue can be summarized as "gamemoderun stops Steam from launching at all", which is considerably more serious than "gamemoderun doesn't have any effect".
libgamemodeauto.so.0seems to also needlibgamemode.so.0in the environment but this dependency doesn't show up withldd /path/to/libgamemodeauto.so.0
pressure-vessel doesn't have any way to know that libgamemodeauto.so.0 is going to need to dlopen libgamemode.so.0.
Even once that change was made I still wasn't seeing the libs get injected into the proton environment
Please attach a detailed log (with STEAM_LINUX_RUNTIME_LOG=1 and STEAM_LINUX_RUNTIME_VERBOSE=1) to the new issue.
I suspect that part of the problem here is that pressure-vessel needs to inject exactly the libraries that are needed, but without the libraries that aren't needed. There's no obvious syntactic difference between something like LD_PRELOAD=libgamemode.so.0, which is maybe safe-ish, and LD_PRELOAD=libssl.so.3, which would defeat the purpose of the Steam Runtime (providing a stable environment) and probably break a lot of older native Linux games. Ideally we should pay attention to the former but not the latter, but we can't read your mind and we don't know which libraries fall into each category, so the best we can do is to use some heuristics.