Compatibility Report

Ok, this is really odd. I left Steam and started it again on the console; and then it worked. I took some time because I have 15 TB of installed games, part of them in HDDs, so it takes a few minutes for Steam to start.

Then I quit Steam, removed compatdata/1655940, started it from the Arch KDE menu as usual, and from there tried to "Play" it again to see if it would rebuild the proton prefix; it didn't. Same issue: compatdata/1655940 with an empty pfx.lock file.

So again I quit Steam and start from the console. Capturing the text via redirection to /tmp/steam-runtime.log, noted the output prior to when I pressed play and discarded them from the log. The game creates the proton prefix and starts normally. I am pasting an editted version of the steam-runtime output because at one time the game was just spitting "LogScript: Warning: Script Msg: Attempted to access index" lines, game messages that was from it already running successfully.

So, we have a reproducible issue, I can't properly do the first run of that game when I run steam via graphical mode. I noticed that the KDE Menu runs steam.desktop, which in turn has that Exec line: Exec=/usr/bin/steam-runtime %U -- so, basically the same I did on the terminal. Also, since I redirected via 2>&1 and to tee (steam-runtime 2>&1 | tee /tmp/steam-runtime.log), it had no controlling terminal, so it's not lack of tty that makes it fail.

editted-steam-runtime.log

And just to confirm: after I have installed and ran the game from steam-runtime from the console, since the proton prefix now was correctly created, it ran successfully after I re-ran steam from the graphical menu.

A few more data:

• This bug does not occur on the steam deck.
• A similar bug just happened with Red Solstice 2: Survivors. Only it created something else on the proton prefix:

/jogos/steam/steamapps/compatdata/768520
├── pfx
│   └── drive_c
│       └── users
│           └── steamuser
│               └── Local Settings
│                   └── Application Data
│                       └── RedSolstice2
│                           └── Save
│                               ├── Campaigns
│                               │   └── steam_autocloud.vdf
│                               ├── Profiles
│                               │   └── steam_autocloud.vdf
│                               └── Suits
│                                   └── steam_autocloud.vdf
└── pfx.lock

Running steam from console, though, completely fixes the issue (even if I do not remove the proton prefix) and finishes the installation of proton successfully, allowing the game to run. So what we might be seing here is something deeper down in the proton prefix creation, and I can't debug it because if it is running on console it works, beating the reproducibility.

How do we reclassify this issue? It does not seem a problem with Earth's Shadow but a general steam client or proton issue.

Ok, I found the culprit in a general way. My user shell is /bin/zsh instead of the most common /bin/bash. Changing the shell for my user to /bin/bash, rebooting and calling steam from the graphical interface works as intended when done this way.

I also created a functional workaround; since in my path /usr/local/bin appears before /usr/bin and /usr/sbin (where steam-runtime is), I've added a shell script /usr/local/bin/steam-runtime that has just these contents:

#!/bin/bash
exec /usr/sbin/steam-runtime "$@"

After doing this, everything worked correctly even after I configured my default shell to be /bin/zsh again and reboot the server: steam installs and launches proton games with no issues.

Now, to locate what's causing this... There has been no new proton updates (and besides, I've tested with different protons), so it must have been something on Steam or the soldier runtime. Any tips on where to look, @kisak-valve ? Also, where should I transfer or file this bug report, since it's (probably) not Proton's?

Kisak, steam-runtime is in /usr/bin actually, but on my arch pacstrap installed sbin as a link to bin and /usr/sbin is before /usr/bin on $PATH so it is mistakenly shown as /usr/sbin/steam-runtime.

Ok... I reverted all my changes, deleted /usr/local/bin/steam-runtime, got my shell back to zsh, and completely uninstalled the two games I was using for testing the issue: Earth's Shadow and Alone In The Dark 1 (the latter because it's tiny, 283 MB). I also had no arch updates in the mean time, nor have I changed any other configuration on the system. But now the bug (which yesterday survived more than 10 reboots yesterday) is not occuring anymore. I don't know what to think of it.

Anyway, I think this issue should be renamed. It's not a compatibility report and so far Earth's Shadow seem to be running ok.

My user shell is /bin/zsh instead of the most common /bin/bash

Do you mean your interactive shell, the 7th field in /etc/passwd (the one you can change with chsh) was zsh, or do you mean /bin/sh was a symlink, hardlink or copy of zsh?

Setting your interactive shell to zsh via chsh is something that should work (I use zsh myself, and some people prefer an entirely non-POSIX shell like fish or csh).

Making /bin/sh a symlink, hardlink or copy of zsh is not supportable, because zsh isn't entirely POSIX-compliant (arguably its deviations from POSIX are an improvement, especially for interactive use, but shell scripts expect a particular set of semantics and zsh doesn't 100% provide those). /bin/sh should be bash (as it is in e.g. Fedora), or dash (Debian/Ubuntu), or some other POSIX shell like one of the various ksh variants.

All of Steam's shell scripts should already be using #!/bin/sh or #!/usr/bin/env bash anyway, so I'm not sure what would be affected by your chosen interactive shell - certainly all the Steam Runtime scripts work that way. In your Steam log, you'll see that when Steam evaluates the game's launch options, it explicitly passes them to /bin/sh as an argument vector.

My user shell is /bin/zsh instead of the most common /bin/bash

Do you mean your interactive shell, the 7th field in /etc/passwd (the one you can change with chsh) was zsh, or do you mean /bin/sh was a symlink, hardlink or copy of zsh?

I was changing shell with the chsh command, so it only changes the 7th field of password. sh on /bin is a symlink to bash.

I am also puzzled of how it could affect proton prefix creation, but informally chatting today another friend was having problems on running games on Steam and I asked him if his user shell was bash -- and it was zsh. I am trying to get him to add his information here.

I can't tell yet whether this is a problem with Steam, or the Steam Runtime, or Proton, or what - the fact that you can't reproduce the bug from a terminal makes it quite difficult to diagnose, because we can't see any warnings or error messages.

If you can reproduce the bug, somehow, then collecting the information from https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information would be useful.

If you're launching Steam from the KDE GUI, it's also worth checking whether its output is getting logged in the systemd journal. If it is, there might be some clues there.

I would expect your interactive shell to be used when you launch a terminal (Konsole or equivalent), and maybe a little bit during login (right at the beginning of your KDE session), but basically nowhere else - so I'm finding it odd that it matters. Do you have any environment variables or other settings relevant to Steam that differ between your ~/.zshrc and ~/.bashrc, or other shell initialization files?

the actual path is /jogos/SteamLibrary... and /jogos/steam is a soft link, but that shouldn't be an issue. There are hundreds of games installed there working for years. The filesystem is /jogos.

It is possible that this is causing trouble for the container framework that is used to run Proton. Symbolic links are not always very container-friendly, because their meaning changes when you start rearranging the filesystem namespace, which containers have to do in order to do their job.

However, if so, I would have expected that to be unrelated to whether your shell is bash or zsh, or whether you ran Steam from a terminal, or whether it's the first run or the second or subsequent run. The logs described in https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information would help to find out.

I can't tell yet whether this is a problem with Steam, or the Steam Runtime, or Proton, or what - the fact that you can't reproduce the bug from a terminal makes it quite difficult to diagnose, because we can't see any warnings or error messages.

Yeah, however I feel that there must be other people affected. I hang out on a linux gaming chat channel and there have been two arch users with /bin/zsh as their shell having some trouble with Steam. As I said, tried to get them to add to this bug report (and I have now changed the title, hope that's ok)

If you can reproduce the bug, somehow, then collecting the information from https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information would be useful.

I will certainly do that if that happens again. But now it stopped, everything works.

If you're launching Steam from the KDE GUI, it's also worth checking whether its output is getting logged in the systemd journal. If it is, there might be some clues there.

That's new to me. What command would get those logs? I just ran journalctl -xe and seen some messages like plasmashell[2616]: Game 470310 created interface SteamUtils007 / Utils, are these useful for debugging?

I would expect your interactive shell to be used when you launch a terminal (Konsole or equivalent), and maybe a little bit during login (right at the beginning of your KDE session), but basically nowhere else - so I'm finding it odd that it matters. Do you have any environment variables or other settings relevant to Steam that differ between your ~/.zshrc and ~/.bashrc, or other shell initialization files?

Yes, there are many different variables. Mind you, one of the steps for me to try and reproduce the issue was doing a bash script that redefined all variables to be like zsh's (unset a bunch of them, set the same variables as zsh, and then call the game). It didn't work. I'm attaching it to the bug report anyway if you find it's useful.

steamdebug.sh.txt

the actual path is /jogos/SteamLibrary... and /jogos/steam is a soft link, but that shouldn't be an issue. There are hundreds of games installed there working for years. The filesystem is /jogos.

It is possible that this is causing trouble for the container framework that is used to run Proton. Symbolic links are not always very container-friendly, because their meaning changes when you start rearranging the filesystem namespace, which containers have to do in order to do their job.

Yeah, but as far as steam itself is aware, the actual path is only /jogos/SteamLibrary/..., I only use /jogos/steam/... when typing on the command line as shortcut, so this shouldn't cause any issues to proton and whatnot

However, if so, I would have expected that to be unrelated to whether your shell is bash or zsh, or whether you ran Steam from a terminal, or whether it's the first run or the second or subsequent run. The logs described in https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information would help to find out.

Will check on that, thanks.

If you're launching Steam from the KDE GUI, it's also worth checking whether its output is getting logged in the systemd journal. If it is, there might be some clues there.

That's new to me. What command would get those logs? I just ran journalctl -xe and seen some messages like plasmashell[2616]: Game 470310 created interface SteamUtils007 / Utils, are these useful for debugging?

Yes, journalctl is the right command, and yes, that looks like a message that is logged by the Steamworks API in a game. That specific message is not particularly interesting, but it does tell us something about how far the game got into startup, so it's indirectly useful.

Unfortunately it looks as though messages logged by apps that are launched by plasmashell (like Steam) are being logged as though they were output from plasmashell itself, rather than being given their own streams, so it won't necessarily be immediately obvious which messages are from Steam and which are from something else. I've opened https://bugs.kde.org/show_bug.cgi?id=461289 for that.

Workaround: just copy everything new that appears in the systemd journal after you launch a game. Or, if people can reproduce this issue in a GNOME session, then messages from Steam should be logged as steam.desktop, which will help to filter them.

as far as steam itself is aware, the actual path is only /jogos/SteamLibrary/..., I only use /jogos/steam/... when typing on the command line as shortcut, so this shouldn't cause any issues to proton and whatnot

OK, if the path used by all Steam components is the real physical path as returned by realpath, then that shouldn't be a problem.

Got a new occurence, bought a bunch of games in the August Steam sales and most of them worked correctly, but an old title wasn't creating the proton prefix, stopping at the empty pfx.lock file too. I suspect some kind of library/segfault. As always, the workaround is to run steam from the terminal and the first run correctly install the proton prefix. Afterwards running the game from steam called from the graphical interface works correctly.

The game is Dark Messiah of Might & Magic (appid 2100).

Would paste the logs but as always steam-2100.log only had the headers and the console output is the expected when it works, so the logs do not show anything new here.

I have reasons to suspect this problem is occuring to many people but as it is very sporadic and for a few titles only, it is being underreported.

Would paste the logs but as always steam-2100.log only had the headers and the console output is the expected when it works, so the logs do not show anything new here.

We are not going to be able to solve this without more clues. Is there anything in the Journal from around the time you launched this game for the first time?

There's nothing in the journal. This bug is perfectly reproducible with this game (2100). If I start Steam from graphical mode, install it, and try to run for the first time, it fails the proton prefix creation. And nothing appears on journalctl -xe -f (I used -f to follow it while it runs).

Got a little more data. It only appears to occur under KDE, and somehow gets cleared out if I install the game under other Desktop Environments even if I completely uninstall it. I tried doing the same thing under:

• IceWM (no compositor)
• Gnome (with Gnome Shell - has a compositor)
  All under X11.
  Both worked. To be thorough before attempting to run I did a complete uninstall of game 2100, removed the proton prefix and installed again.
  I also tested under KDE before a couple times with complete uninstallations just to be sure. It failed the same way. So this is something in KDE/kwin or something.
  However, when I tried it after having gone through the other DE's and two reboots, and having completely uninstalled and removed the remainders of the proton prefix (the empty 2100 directory), I can install and run it successfully from KDE.

This is quite weird, maybe there's some KDE app state machine that somehow conflicts with the proton prefix creation? And then stops conflicting after a successful first run for some reason, even if the game is completely uninstalled.

It is of note that since it's KDE, it might eventually affect the Steam Deck.
Steam Deck's KDE / kwin version is 5.23.5:

(deck@steamdeck ~)$ pacman -Q | egrep 'kwin |plasma-workspace[^-]' 
kwin 5.23.5-1
plasma-workspace 5.23.5-5

My arch version of the same packages is 5.26.3-1:

[20:27] [7886] [patola@risadinha patola]% pacman -Q | grep -E 'kwin |plasma-workspace[^-]'
kwin 5.26.3-1
plasma-workspace 5.26.3-1

Just to make it clear: I'm still using zsh as default shell, as I was before this bug report (I reverted all my bash-related changes).

It only appears to occur under KDE
the workaround is to run steam from the terminal

This is reminding me of ValveSoftware/steam-for-linux#8069, where launching Steam with a keyboard shortcut or a desktop widget was making the steamwebhelper fail because stdout/stderr were pointing to a pseudo-terminal that no longer existed.

Do you restart KDE from within KDE, like in https://github.com/ValveSoftware/steam-for-linux/issues/8069#issuecomment-954081641?

If not that, how precisely do you start KDE? (Do you run it from a text console? Do you launch it from the sddm GUI? Is it a systemd service? etc.)

If this is similar to 8069, then gathering the same information that I asked for in https://github.com/ValveSoftware/steam-for-linux/issues/8069#issuecomment-945207871 and https://github.com/ValveSoftware/steam-for-linux/issues/8069#issuecomment-954072837 might be useful.

It only appears to occur under KDE
the workaround is to run steam from the terminal

This is reminding me of ValveSoftware/steam-for-linux#8069, where launching Steam with a keyboard shortcut or a desktop widget was making the steamwebhelper fail because stdout/stderr were pointing to a pseudo-terminal that no longer existed.

Do you restart KDE from within KDE, like in ValveSoftware/steam-for-linux#8069 (comment)?

If not that, how precisely do you start KDE? (Do you run it from a text console? Do you launch it from the sddm GUI? Is it a systemd service? etc.)

YES! In fact, for some reason KDE's taskbar crashes often and I issued the exact commands (kquitapp5 plasmashell; kstart5 plasmashell) to bring it back. That's a variable I failed to mention, indeed, as it turned into habit, sorry.

Anyway, right now I don't see the two deleted file descriptors, also not experiencing the issue even though I restarted plasmashell (tried with a few games and Dark Messiah of Might and Magic is also not having the issue now):

[22:23] [7929] [patola@risadinha patola]% pgrep steam | sort -n | head -1
3972
[22:23] [7930] [patola@risadinha patola]% ls -la /proc/3972/fd/[012]     
lr-x------ 1 patola patola 64 Nov 23 20:26 /proc/3972/fd/0 -> 'pipe:[67722]'
lrwx------ 1 patola patola 64 Nov 23 20:26 /proc/3972/fd/1 -> 'socket:[61724]'
lrwx------ 1 patola patola 64 Nov 23 20:26 /proc/3972/fd/2 -> 'socket:[61724]'

steam's parent process is this one:
patola 3792 2669 0 Nov23 ? 00:00:00 bash /home/patola/.local/share/Steam/steam.sh

I've attached the output of systemd-cgls as a text file to avoid cluttering the bug report, but since the problem is not happening right now, I think it will not be too useful. However, as soon as I experience the issue again I will be sure to paste the information.

systemd-cgls.txt

YES! In fact, for some reason KDE's taskbar crashes often and I issued the exact commands (kquitapp5 plasmashell; kstart5 plasmashell) to bring it back. That's a variable I failed to mention, indeed, as it turned into habit, sorry.

If this is the same as 8069, then the steps to reproduce the bug would be:

1. Be in a terminal (Konsole or xterm or similar). Run tty in that terminal to identify where you are; the result should be something like /dev/pts/24.
2. Relaunch Plasma Shell with kquitapp5 plasmashell; kstart5 plasmashell or similar. This is setting you up for problems later, but the issue probably won't appear yet.
3. At this point, launching Steam is still OK. If you look in its /proc/(pid)/fd, you will see that fds 1 and 2 point to the same terminal device that you identified in step 1 (/dev/pts/24 in my example).
4. Close the terminal: this is probably the key step to reproduce the bug.
5. Now Steam is in a bad state, because its stdout/stderr (/proc/(pid)/fd/1 and /proc/(pid)/fd/2) point to a terminal that no longer exists; if you look in /proc/(pid)/fd again (perhaps from a different terminal), you'll see that the kernel reports it as something like /dev/pts/24 (deleted).
6. Anything launched by Steam that tries to write messages with error-checking will get a write error, and fail. You can verify this by deleting the compatdata/(game ID) folder for a Windows game (or just moving it out of the way if it contains settings, saved games etc. that you want to keep), and then trying to start that game.

Does that trigger the bug?

I suspect that what might be happening is something like this. Proton starts as a Python script, and Python tends to have more thorough error-checking than shell scripts or C/C++ code; so when it tries to log a message to stderr, the write fails with an exception and the Python script crashes. You don't see an error message for the same reason that it failed: it's trying to write to a terminal that no longer exists, so the error message goes nowhere.

Worse, as soon as you try to debug this, it seems to work, because while debugging you launched Steam from a terminal that is still running!

Similarly, if you try to debug it with PROTON_LOG=1 %command% in a game's Launch Options, then the game itself will try to start, because now Proton is writing its output to a log file instead of to the disappeared terminal, so the writes succeed. However, the Launch Options only affect the game itself, and are ignored when running smaller commands in preparation for launching the game - so for example creating the prefix already failed, and launching the game probably doesn't work as a result.

The fact that you switched between zsh and bash is probably not relevant, except that in order to change your shell, you logged out and back in (or rebooted), which had the side-effect of putting Plasma Shell back into a more reasonable state (at least until the next time you restarted it).

If I am correct about this then there are some workarounds:

• Don't restart Plasma Shell mid-session. If it stops working, report that to your OS vendor as a bug, then log out and back in to restart the whole session "cleanly".
• Or, if you must restart Plasma Shell mid-session, send its output to the systemd Journal: kquitapp5 plasmashell; systemd-cat -t plasmashell-restarted kstart5 plasmashell.
• Or send its output to a log file: kquitapp5 plasmashell; kstart5 plasmashell >> ~/plasmashell.log 2>&1.
• Or, add a shell script wrapper for Steam that similarly sends its output to the systemd Journal or to a log file.

I was able to reproduce a simplified version of this issue like this:

• Open a terminal. I used gnome-terminal rather than Konsole because I happened to have started a GNOME system, but it shouldn't matter which one you use.
• In that terminal, run steam &. (On Arch you might need to run steam-runtime & instead.)
• In another terminal, ls -l /proc/$(pgrep steam|head -n1)/fd/[012]. In my case all three standard file descriptors point to /dev/pts/0.
• Exit from the first terminal.
• In the other terminal, ls -l /proc/$(pgrep steam|head -n1)/fd/[012] again. Now all three standard file descriptors are listed as /dev/pts/0 (deleted).
• Delete the compatdata for an expendable test game that runs under Proton. I'm using The Expendabros (which is small and free-to-play) as my test title, so I deleted compatdata/312990.
• It fails to launch.

This is a bit more direct than the situation that I think you're seeing. In the case where you restart Plasma Shell and then launch Steam from something provided by Plasma (a menu or global keyboard shortcut or desktop widget or similar), the problem is that Steam inherits the output and error file descriptors (the terminal) from Plasma Shell, and if those file descriptors are broken/unusable then it also inherits that brokenness.

Restarting your desktop environment from a terminal running inside your desktop environment is a bit like standing on a ladder and sawing off the tree branch your ladder is leaning on, so I'm not really surprised it causes weird behaviour.

I've proposed a workaround for Proton (#6341), but it's very, very common for applications, libraries and tools to assume that the standard file descriptors are set to something reasonable, so there will almost certainly be other things that fail in a similar way: for instance ValveSoftware/steam-for-linux#8069 was essentially the same thing, but in the script that launches Steam's web runtime. If you need to work around desktop environment bugs by restarting components of it, I'd recommend doing that in a more controlled way by logging out and back in (or rebooting), instead of restarting individual components from an unexpected execution environment.

I also started looking at how/whether Steam's container runtime could detect and work around this, but that's both harder and less useful than it sounds, so we're probably not going to pursue that. The expected behaviour for any program is that it writes output to the file descriptors that it inherited from its parent, so redirecting output when it wasn't asked for would also be a bug; and the file descriptor might be valid during startup but become invalid while the program is running, so a check during startup isn't enough to prevent this failure mode.

Indeed, the difference is that this way you proposed it also deleted file descriptor 0, not only 1 and 2:
Before closing the terminal:

[20:12] [7997] [patola@risadinha patola]% ls -l /proc/$(pgrep steam|head -n1)/fd/[012]
lrwx------ 1 patola patola 64 Nov 25 20:12 /proc/110312/fd/0 -> /dev/pts/0
lrwx------ 1 patola patola 64 Nov 25 20:12 /proc/110312/fd/1 -> /dev/pts/0
lrwx------ 1 patola patola 64 Nov 25 20:12 /proc/110312/fd/2 -> /dev/pts/0

After disown-ing the job and closing the terminal:

[20:14] [7998] [patola@risadinha patola]% ls -l /proc/$(pgrep steam|head -n1)/fd/[012]
lrwx------ 1 patola patola 64 Nov 25 20:12 /proc/110312/fd/0 -> '/dev/pts/0 (deleted)'
lrwx------ 1 patola patola 64 Nov 25 20:12 /proc/110312/fd/1 -> '/dev/pts/0 (deleted)'
lrwx------ 1 patola patola 64 Nov 25 20:12 /proc/110312/fd/2 -> '/dev/pts/0 (deleted)'

After Steam started and I pressed "play", I could consistently reproduce the issue (using AppID 2130 as example here):

[20:25] [7998] [patola@risadinha patola]% ls -l /jogos/steam/steamapps/compatdata/2130
total 4
drwxr-xr-x 3 patola patola 4096 Nov 24 22:31 pfx
-rwxr-xr-x 1 patola patola    0 Nov 25 20:24 pfx.lock
[20:25] [8000] [patola@risadinha patola]% du -sh /jogos/steam/steamapps/compatdata/2130
12K     /jogos/steam/steamapps/compatdata/2130

BTW, I changed the bug report's title now that we found the culprit. It's important for people with the same problem to find this report.

BTW, I changed the bug report's title now that we found the culprit. It's important for people with the same problem to find this report.

Thanks, but perhaps "Profile creation fails after restarting KDE from a terminal" would be better? It's really the restart and the terminal that are the key things causing this, not the fact that it's KDE (although in both the issues where I've seen this, it was KDE, so maybe this way to restart desktop components is a meme in the KDE community).

If you logged out and back in (which is the only way to restart some non-KDE desktop environments, like GNOME) then this wouldn't happen; or if you restarted the Plasma session, but as a systemd unit rather than with kstart5 in an interactive terminal, this also wouldn't happen.

the difference is that this way you proposed it also deleted file descriptor 0, not only 1 and 2

Yes, it looks like KDE might always give us a pipe as fd 0 (standard input), but for simplicity my reproducer treats fd 0 the same as 1 and 2.

File descriptors 1 and 2 (standard output and standard error) are much more important than standard input for games and compatibility tools, because games and compatibility tools often write diagnostic messages to stdout or stderr (and in particular I think Proton always writes at least one diagnostic message to stderr), but it's rare for something other than an interactive CLI tool to read from stdin.