search

ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.22k stars 174 forks source link

Steamwebhelper Broken (Black Screen) If Stdout/Stderr Not Redirected #8069

Closed TakuyaSama closed 2 years ago

TakuyaSama commented 3 years ago

Your system information

Please describe your issue in as much detail as possible:

I have the Black Screen issue since 10th September, the moment I updated the Steam Client. I updated Steam on my Arch system, the 10th September, it self updated first, then I updated the system, (and I updated freetype2 too, to 2.11.0 finally, after having it frozen because of its issue with previous stable Steam version). I tried what's described on issue #8056, but that didn't fix my issue. I'm having to use the Small Mode since then to launch my only game installed, and I think that's causing an issue, I just noticed I can't open the Steam's properties of that game, so I can't edit the launch options (I have it a little bit modified), cause I wanted to add the gamemode option. I think that using the Small Mode is causing an issue with Telegram Desktop when I'm on a Voice Chat with a mate, we play together, and sometimes on Warframe, when I realize some kind of connection in-game, the mic stops working, and I have to mute and unmute to have it working again and that issue just started since the inability of having Steam launched on the normal mode.

Steps for reproducing this issue:

  1. Launching Steam.
  2. See the black screen instead of the normal loaded homepage, with the news.
Technohacker commented 3 years ago

Status update! Launch from menu now renders the window content correctly on Plasma/KWin with Flatpak Steam. It may have been a Flatpak update that fixed it for me, but I can't say for certain, annoyingly enough. History command doesn't work :/

Steam output on journal now shows up as expected, I'll try to get the list of packages updated

smcv commented 3 years ago

@theaprilhare:

steamwebhelper.sh: line 28: echo: write error: Broken pipe

This means steamwebhelper.sh (and probably all of Steam) has been invoked with stdout directed to a pipe for which the read end has been closed.

This message appears on stderr, so at least you have now managed to get Steam invoked with stderr directed to somewhere that you can read.

If you're running systemd-cat --identifier=sway sway, then sway's stdout and stderr should both be the systemd Journal, so I can only assume that stdout was reopened as a pipe somewhere internal to sway.

theaprilhare commented 3 years ago

@smcv:

This message appears on stderr, so at least you have now managed to get Steam invoked with stderr directed to somewhere that you can read.

Assuming the lines you quoted above (Loaded SDL version 2.0.17-6744061, etc.) are from stdout, that seems to be going into the journal as well. Here is a gist of everything that's being sent into the journal when I launch Steam from wofi.

smcv commented 3 years ago

@theaprilhare:

/bin/sh: line 1: Running: command not found

This looks like something is wrong somewhere in your app-launcher setup, with a command parsing something that was intended to be a human-readable diagnostic message?

Assuming the lines you quoted above (Loaded SDL version 2.0.17-6744061, etc.) are from stdout

I think they're more likely to be from stderr. If stdout was a Journal stream, then you wouldn't be getting echo: write error: Broken pipe.

theaprilhare commented 3 years ago

@smcv You were quite right – the issue is that in "drun" mode (unlike "dmenu" mode) wofi actually runs the requested program instead of simply printing the command used to launch it to stdout (where it would be piped to xargs swaymsg exec --). To get the latter behavior, you've got to add drun-print_command=true to your wofi configuration. Upon doing so, things work as expected.

This solves the issue as far as I'm concerned. I expect there was some change to Steam a few weeks ago that caused steamwebhelper to fail when its stdout was pointing nowhere (since things were working before that), but since it's entitled to expect that its stdout actually goes somewhere, it doesn't seem to be a Steam issue (as opposed to a me issue, sorry).

I reckon the issues @TakuyaSama and @edward-shen are experiencing have a related, but not identical, etiology since they're presumably not using a misconfigured wofi but may be directing their stdout somewhere that fills up – but won't speak for them. Thanks very much for all the help.

TakuyaSama commented 2 years ago

Update, even after updating to the latest Steam client, built October 6th, the issue persists, I still have to do that "workaround" of editing the file at /usr/bin/steam-runtime so I can launch it normally with my keyboard shortcut configured on Plasma, with Meta + G. I tried to comment that line and still persists, to my concern

@theaprilhare, you mentioned Krunner. Does this mean you are also using KDE?

I think it was @TakuyaSama who mentioned Krunner; I'm not using KDE and use wofi as my launcher.

Yeah, I mentioned KRunner, but I usually don't use it to launch, I have to launch it that way if I decomment the line I added (I don't remember what mate here on this issue was the one who said it fixed it for him sorry). I usually use the keyboard shortcut so I can avoid using my mouse to launch the software I use most commonly. I have configured on that Plasma's System Setting module, the entry which says Steam (Runtime), and when I add Steam to configure it, it shows itself as Steam (Runtime).

Sorry for being a bit disconnected from this issue I opened up. I'm now ready to do the required tests to try to find the issue and once located, give the devs that info, so they can see if they can workaround it or if it's caused by other software.

@smcv Simon, sorry mate, I'm ready now.

smcv commented 2 years ago

@TakuyaSama:

I usually use the keyboard shortcut

Unfortunately, I was still not able to reproduce this bug.

Here is what I tried to do to reproduce this. If what you did is different, please describe it with a similar level of detail, and when things start to go wrong, please show me any log messages you get at that stage, from any source.

Please assume that I don't regularly use KDE/Plasma - things that are obvious to a regular KDE/Plasma user are not necessarily obvious to me.

Preparation

Baseline: Steam running from a terminal

Steam running from a custom shortcut

Steam running from an application shortcut

I found that this did not reliably start Steam - more likely a KDE/Plasma or OS bug than a Steam bug? I don't know what was happening here. In the cases where Steam didn't start, pgrep steam showed no Steam processes running.

Expected result

In all cases, the expected result is that Steam and the steamwebhelper launch successfully, and the Library, Store, etc. have their usual content.

Actual result

Your bug report was that the steamwebhelper does not launch successfully, resulting in the Library, Store, etc. being empty black rectangles. I couldn't reproduce this.

Workaround

You previously mentioned that editing /usr/bin/steam-runtime to redirect standard output and standard error to a log file was a successful workaround for this.

From other users' comments, it seems that it might be sufficient to only redirect standard output, and leave standard error un-redirected, something like this:

#!/bin/sh
exec > "$HOME/steam-stdout.log"
exec /usr/lib/steam/steam "$@"

Is that sufficient? If it is, then that tells us something about the issue.

TakuyaSama commented 2 years ago

Please assume that I don't regularly use KDE/Plasma - things that are obvious to a regular KDE/Plasma user are not necessarily obvious to me.

Preparation

* Have an up-to-date Arch Linux installation with KDE Plasma Desktop. I used:

  * plasma-desktop 5.22.5-1
  * plasma-workspace 5.22.5-2
  * plasma-framework 5.87.0-1
  * sddm 0.19.0-7
  * steam 1.0.0.72-2
  * I don't know which other packages are particularly relevant to KDE/Plasma, but if there are other packages that are particularly relevant, please say what versions they are at

* Log in to sddm as a user

  * In case it matters, I used the Plasma X11 session type; I have Wayland integration installed but I didn't enable it

* Open a terminal: I used Konsole

* In the terminal, run `steam-runtime`

* Check for updates and let Steam update itself, if necessary (I'm currently using the public beta, built Oct 6 2021, Steam package version 1633666232)

* Completely exit from Steam

* Wait for the shell prompt to appear again

  * If you are getting `Thread "CJobMgr::m_WorkThreadPool:xxx" (ID xxx) failed to shut down`, this might take a while - potentially several minutes. That's

Don't worry, it's normal that you're not usual to KDE Plasma, I'll try my best to explain myself and my use case so you can follow it as easiest as possible.

Starting with I'm on Plasma 5.23 (package 5.22.90 version), since almost a month, the stable release of Plasma 5.23 is going to be released in about 2 days or so, maybe the issue is coming from that side, I can't deny it, because I'm not sure.

I also use Wayland session as my default and daily driver session since about 2 years, (Plasma 5.17 if I'm not wrong), maybe that could be another point causing possibles issues.

I said it at first time, launching steam-runtime from terminal (Alacritty in my case), works flawlessly, as it should.

Steam running from an application shortcut

I found that this did not reliably start Steam - more likely a KDE/Plasma or OS bug than a Steam bug? I don't know what was happening here. In the cases where Steam didn't start, pgrep steam showed no Steam processes running.

* Plasma main menu -> Settings -> System Settings

* left sidebar -> Workspace -> Shortcuts -> Shortcuts

* Click on `+ Add Application...`

* Choose `Steam (Runtime)`, click OK

* Choose the `Steam` action in the right panel

* `+ Add custom shortcut`

* Click on the Input button, then assign a key combination (I used Ctrl+Alt+Shift+L)

* Apply

* Exit from System Settings

* Check that there are no Steam processes running

  * `pgrep steam`
  * systemd-cgls` might also help

* Press the shortcut key combination you chose

* Wait for Steam to start

* Expected result: The web views work correctly, and you can browse your Library and the Store

* While you have Steam open, use `pgrep steam` to find Steam processes, and check `ls -l /proc/$pid/fd/[012]`, replacing `$pid` with the process ID of the top-level Steam process. Here's what I get:

  * `0 -> pipe:[42819]`
  * `1 -> socket:[25746]`
  * `2 -> socket:[25746]`

* I would expect each of them to be either a systemd-journald socket, or a log file, or `/dev/null`.

* If file descriptors 0, 1 or 2 are pointing to a pipe (like my fd 0 is), then that's _potentially_ a bug. It might be useful if you are able to [find out what (if anything) is at the other end](https://github.com/ValveSoftware/steam-for-linux/issues/8069#issuecomment-927380441).

* If file descriptor 2 is pointing to a log, check that log file to see whether there are error messages in it.

* If file descriptors 1 and/or 2 are pointing to a `socket:`, it's _probably_ the systemd Journal. Check the journal with `journalctl` to see whether there are error messages in it.

* Also check `~/.local/share/Steam/logs/steamwebhelper.log` to see whether there are error messages in it.

* Completely exit from Steam.

* Wait for all Steam processes to exit (`pgrep steam` should output nothing). Again, this might take a while.

This is where I'm having the issue yeah. I have tried changing the actions from the panel, but with same result. This is my standard way to launch Steam, since many months ago, I don't tend to use Custom Shortcuts unless I can't launch what I want from standard Shortcuts. What you say about this method isn't really reliably launching Steam bothers me and may be the source of the issue, I don't know, like I said before, Plasma 5.23 is being released in a few days, so I should be able to test it out soon and see if the issue was coming from Plasma 5.23 Beta or from Steam. I just checked it out and the official stable release is October 14th, so I hope at the latest, the next weekend I have Plasma 5.23 installed so I can check this.

Workaround

You previously mentioned that editing /usr/bin/steam-runtime to redirect standard output and standard error to a log file was a successful workaround for this.

From other users' comments, it seems that it might be sufficient to only redirect standard output, and leave standard error un-redirected, something like this:

#!/bin/sh
exec > "$HOME/steam-stdout.log"
exec /usr/lib/steam/steam "$@"

Is that sufficient? If it is, then that tells us something about the issue.

I tried this workaround and yeah, it works fine, I left the file as you indicated here, and it works perfectly fine.

Thank you very much as always for your work, efforts and patience with me mate, honestly.

savely-krasovsky commented 2 years ago

@theaprilhare drun-print_command=true option helps, but it breaks other software like Thunar or Remmina :(

smcv commented 2 years ago

@L11R: Because the original report was from a KDE Plasma user, I think we should consider similar symptoms from Sway/wofi/dmenu/kickoff users such as @theaprilhare, @edward-shen and (presumably) you to be a separate issue that is off-topic for this particular issue report, to avoid this issue report becoming even more confusing than it already is.

From Steam's point of view, the bottom line is that Steam, like many other applications, expects to be able to write to standard output; and if it can't do that, it will not work reliably. If you don't know or can't tell what will happen when Steam writes to standard output, or if you are unable to give Steam a reasonable file descriptor for standard output without breaking other applications' assumptions, then perhaps consult your desktop environment's community or your application launcher's community, or reconsider whether a kit to build your own application launcher from shell pipelines is the most suitable approach for you to be using.

TakuyaSama commented 2 years ago

The same situation/issue with Steam updated to build of October 13th. Waiting for Plasma 5.23 to be reaching the stable repos on my distro, it was released almost 1 day ago, it should be on stable repos today or tomorrow, hopefully. I'll keep you updated.

TakuyaSama commented 2 years ago

I just updated to Plasma 5.23 Stable and the issue persists :(. It seems that it's a Steam issue then, not from KDE's part.

smcv commented 2 years ago

While you have Steam open, please use pgrep steam to find Steam processes, then check ls -l /proc/$pid/fd/[012], replacing $pid with the process ID of the top-level Steam process.

I think there is a workaround that Steam can use, but I want to know what we are working around first.

ligix commented 2 years ago

While you have Steam open, please use pgrep steam to find Steam processes, then check ls -l /proc/$pid/fd/[012], replacing $pid with the process ID of the top-level Steam process.

Black screen (ran via Plasma Application Menu widget):

~ 0s
➜ pgrep steam # Note no -x
981179
~ 0s
➜ ls -l /proc/981179/fd/{0..2}
lr-x------ 1 doggo doggo 64 28 ott 18.42 /proc/981179/fd/0 -> 'pipe:[29288052]'
lrwx------ 1 doggo doggo 64 28 ott 18.42 /proc/981179/fd/1 -> '/dev/pts/4 (deleted)'
lrwx------ 1 doggo doggo 64 28 ott 18.42 /proc/981179/fd/2 -> '/dev/pts/4 (deleted)'

Not black (ran steam-runtime in the terminal):

~ 0s
➜ pgrep steam
982781
982791
982792
982844
982864
982890
983215
983253
983267
~ 0s
➜ pgrep -x steam # -x for exact else you get stuff like steamwebhelper
982781
982791
~ 0s
➜ ls -l /proc/982781/fd/{0..2}
lrwx------ 1 doggo doggo 64 28 ott 18.46 /proc/982781/fd/0 -> /dev/pts/6
lrwx------ 1 doggo doggo 64 28 ott 18.46 /proc/982781/fd/1 -> /dev/pts/6
lrwx------ 1 doggo doggo 64 28 ott 18.46 /proc/982781/fd/2 -> /dev/pts/6
~ 1s
➜ ls -l /proc/982791/fd/{0..2}
lrwx------ 1 doggo doggo 64 28 ott 18.44 /proc/982791/fd/0 -> /dev/pts/6
lrwx------ 1 doggo doggo 64 28 ott 18.44 /proc/982791/fd/1 -> /dev/pts/6
lrwx------ 1 doggo doggo 64 28 ott 18.44 /proc/982791/fd/2 -> /dev/pts/6
smcv commented 2 years ago

@GodSaveTheDoge writes:

lrwx------ 1 doggo doggo 64 28 ott 18.42 /proc/981179/fd/1 -> '/dev/pts/4 (deleted)'

OK, this is weirder than I thought... it seems the Plasma application menu is somehow running processes with their stdout/stderr set to a pseudoterminal that doesn't exist any more.

This seems like either a bug in the application menu, or a bug in a higher-level component that started the application menu. I'm not surprised Steam doesn't like this.

@GodSaveTheDoge, what operating system and desktop environment are you using (including version numbers, etc.) and how do you start the desktop environment?

I suspect that unlike @TakuyaSama, you will find that if you redirect only stdout (as in the last part of https://github.com/ValveSoftware/steam-for-linux/issues/8069#issuecomment-939989700), it will not work around this issue for you.

There is a reasonable way to work around what @TakuyaSama was seeing (stop writing diagnostic messages to stdout, write them to stderr instead); but I don't think there is a reasonable way for Steam to work around its stderr also being wrong. I think this is something that would need to be fixed in the OS or desktop environment.

smcv commented 2 years ago

@TakuyaSama, I'm still waiting for the equivalent of https://github.com/ValveSoftware/steam-for-linux/issues/8069#issuecomment-954021670 from you.

ligix commented 2 years ago

@GodSaveTheDoge, what operating system and desktop environment are you using (including version numbers, etc.) and how do you start the desktop environment?

Arch, plasma, sddm.

linux: 5.14.14.arch1-1
plasma-desktop:  5.23.2-1
sddm:  0.19.0-7
steam: 1.0.0.72-2
ligix commented 2 years ago

I suspect that unlike @TakuyaSama, you will find that if you redirect only stdout (as in the last part of #8069 (comment)), it will not work around this issue for you.

Nope. Adding exec > "$HOME/steam-stdout.log" to /usr/bin/steam fixes it.

smcv commented 2 years ago

Nope. Adding exec > "$HOME/steam-stdout.log" to /usr/bin/steam fixes it.

Hmm, that might be because steamwebhelper.sh doesn't currently log anything to stderr, only to stdout; so even if they're equally broken, stdout is maybe the only one that matters right now.

ran via Plasma Application Menu widget

Please could you describe in more detail what this means, similar to what I wrote in https://github.com/ValveSoftware/steam-for-linux/issues/8069#issuecomment-939989700?

smcv commented 2 years ago

Trying to reproduce this again. Arch Linux, plasma-workspace 5.23.2-1, plasma-desktop 5.23.2-2, sddm 0.19.0-7, steam 1.0.0.72-2, running in X11 mode; Steam 1635319913 (2021-10-27 07:06:24).

Steps to try to reproduce:

@GodSaveTheDoge, is this the equivalent of what you do?

As before, I could not reproduce the issue reported here. Steam started successfully and the webview works.

For me, Steam's fd 0 is a pipe, fd 1 is /dev/null and fd 2 is /home/desktop/.local/share/sddm/xorg-session.log (where desktop is my username on the test machine).

So I think the next question is: why is this the case for me (with a relatively boring Arch installation that I have not customized extensively), but not for you?

smcv commented 2 years ago

For completeness: it looks like I accidentally used the Flatpak version of Steam for that test, instead of Arch's OS-native Steam package. I retried the same steps, but using Steam (runtime), and the result was the same.

smcv commented 2 years ago

Another thing that might be a useful source of information:

For me, the answer is that the parent of the highest-level steam process 10086 is bash process 8945 running steam.sh, which was run by the plasmashell process, which is daemonized and is part of my desktop session:

$ pstree -p
systemd(1)─┬ ...
...
           ├─plasmashell(692)─┬─bash(8945)───steam(10086)─┬─...
...
$ systemd-cgls
Control group /:
-.slice
├─user.slice 
│ └─user-1000.slice 
│   ├─user@1000.service 
...
│   │ ├─app.slice 
...
│   │ │ ├─app-steam-3563348e478c416ea47325ba1988491c.scope 
│   │ │ │ ├─ 8945 bash /home/desktop/.steam/debian-installation/steam.sh
│   │ │ │ ├─10086 /home/desktop/.steam/debian-installation/ubuntu12_32/steam
...
│   ├─session-2.scope 
│   │ ├─566 /usr/lib/sddm/sddm-helper --socket /tmp/sddm-auth[redacted] --id 1 --start /usr/bin/startplasma-x ...
│   │ ├─580 /usr/bin/kwalletd5 --pam-login 7 8
│   │ ├─581 /usr/bin/startplasma-x11
│   │ ├─610 /usr/lib/kf5/start_kdeinit
│   │ ├─611 kdeinit5: Running...
│   │ ├─613 /usr/lib/kf5/klauncher --fd=9
│   │ ├─643 /usr/bin/kded5
│   │ ├─647 /usr/bin/kwin_x11
│   │ ├─684 /usr/bin/ksmserver
│   │ ├─692 /usr/bin/plasmashell
│   │ ├─699 /usr/bin/kaccess
│   │ ├─701 /usr/lib/org_kde_powerdevil
│   │ ├─706 /usr/lib/polkit-kde-authentication-agent-1
│   │ ├─723 /usr/bin/xembedsniproxy
│   │ ├─726 /usr/bin/gmenudbusmenuproxy
│   │ ├─732 /usr/lib/kdeconnectd
│   │ ├─737 /usr/lib/DiscoverNotifier
│   │ ├─795 /usr/lib/geoclue-2.0/demos/agent
│   │ ├─797 /usr/bin/kmix --keepvisibility
│   │ ├─994 /usr/lib/kf5/kioslave5 /usr/lib/qt/plugins/kf5/kio/kio_file.so file  local:/run/user/1000/kded5LvcxQA.1.slave-socket
│   │ └─996 /usr/lib/kf5/kioslave5 /usr/lib/qt/plugins/kf5/kio/kio_file.so file  local:/run/user/1000/kded5OPyxFr.2.slave-socket

(This machine multi-boots several different distributions, which is why my Steam installation starts at ~/.steam/debian-installation instead of the usual ~/.local/share/Steam, but that shouldn't matter here.)

ligix commented 2 years ago

@GodSaveTheDoge, is this the equivalent of what you do?

I think so. The only differences I can spot is not rebooting and restarting plasma (kquitapp5 plasmashell; kstart5 plasmashell) (now that I think about it you asked me earlier and I answered sddm... oops.)

~ 0s
➜ uptime # didn't reboot since last update
 19:58:30 up 14 days,  4:46,  7 users,  load average: 3.32, 2.36, 2.38
~ 0s
➜
smcv commented 2 years ago

The only differences I can spot is not rebooting and restarting plasma (kquitapp5 plasmashell; kstart5 plasmashell) (now that I think about it you asked me earlier and I answered sddm... oops.)

We might be onto something here.

How do you get from a cold boot to a usable desktop environment?

Where and how do you run kquitapp5 plasmashell; kstart5 plasmashell?

smcv commented 2 years ago

I tried this:

Now my plasmashell process has its fds 1 and 2 connected to /dev/pts/2 (deleted). When I relaunch Steam from the widget, it also has /dev/pts/2 (deleted) for its stdout and stderr, and I can reproduce the symptom you describe.

I think this is a broken situation to get into: apps like Steam should be able to assume that they are invoked with their stdout and stderr pointing to somewhere reasonable.

Is restarting plasmashell like this something that is generally considered to be supported among KDE/Plasma users?

smcv commented 2 years ago

@TakuyaSama, did you restart Plasma in a similar way?

ligix commented 2 years ago

How do you get from a cold boot to a usable desktop environment?

sddm but sometimes I restart plasmashell (which of course already happened since I haven't rebooted for 2 weeks).

Where and how do you run kquitapp5 plasmashell; kstart5 plasmashell?

Open st (terminal emulator) and just run it.

Is restarting plasmashell like this something that is generally considered to be supported among KDE/Plasma users?

I'm not sure if it is or not but you can find plenty of forum posts mentioning it.

Another fix would be to just redirect stdout and stderr to something that won't be deleted when you close the terminal. kquitapp5 plasmashell; kstart5 plasmashell &> /dev/null.

smcv commented 2 years ago

Another fix would be to just redirect stdout and stderr to something that won't be deleted when you close the terminal. kquitapp5 plasmashell; kstart5 plasmashell &> /dev/null

Yes, that would make sure that apps started by your Plasma environment don't crash when they discover that they can't write to their stderr. Or you could use systemd-cat kstart5 plasmashell to send its output to the system log.

The reason this is causing problems for the Steam web helper, specifically, is that the Steam web helper is launched by a shell script. To make the shell script more robust, it uses set -e, so that it will stop when a command fails, instead of continuing and hoping for the best. However, when our stdout/stderr is a terminal that no longer exists, writing a diagnostic message with echo will fail, and that counts as a command that failed (echo is just a command like any other), so the script stops.

It should be possible to work around this in Steam by ignoring errors while showing diagnostic messages, but that isn't really something that should be necessary. I suspect that Steam isn't the only thing that will break in strange ways when run like this.

ligix commented 2 years ago

The reason this is causing problems for the Steam web helper, specifically, is that the Steam web helper is launched by a shell script. To make the shell script more robust, it uses set -e, so that it will stop when a command fails, instead of continuing and hoping for the best. However, when our stdout/stderr is a terminal that no longer exists, writing a diagnostic message with echo will fail, and that counts as a command that failed (echo is just a command like any other), so the script stops.

Maybe redirecting to /dev/null if stdout doesn't exist?

It should be possible to work around this in Steam by ignoring errors while showing diagnostic messages, but that isn't really something that should be necessary. I suspect that Steam isn't the only thing that will break in strange ways when run like this.

I never had any troubles outside of steam but that's just me

smcv commented 2 years ago

Maybe redirecting to /dev/null if stdout doesn't exist?

"Doesn't exist" is more complicated than you might think: pipes and sockets are perfectly reasonable destinations for output, but don't "exist" as files. A better workaround is probably to ignore errors when writing diagnostic messages from shell scripts with set -e, but this will take a bit of time to get through the release process.

ligix commented 2 years ago

"Doesn't exist" is more complicated than you might think

if ! echo "a"; then exec &> /dev/null; fi

"Checking if stdout is writable" or something like that might be a better fit than "a".

smcv commented 2 years ago

It should be possible to work around this in Steam by ignoring errors while showing diagnostic messages

That change is included in Steam public beta 2021-11-02 (build 1635884102), which should resolve the issue as reported here.

The "Steam Linux Runtime" compat tools do not have an equivalent change included in their scripts yet, but it is in the queue for the next beta of each one.

if ! echo "a"; then exec &> /dev/null; fi

That wouldn't actually solve this; it's possible for stdout/stderr to be valid at startup but become invalid later.

smcv commented 2 years ago

That change is included in Steam public beta 2021-11-02 (build 1635884102), which should resolve the issue as reported here

This update also appears to have gone out in the general availability channel now (in version: 2021-11-19 20:59:59, 1637358733).

TakuyaSama commented 2 years ago

That change is included in Steam public beta 2021-11-02 (build 1635884102), which should resolve the issue as reported here

This update also appears to have gone out in the general availability channel now (in version: 2021-11-19 20:59:59, 1637358733).

It seems so, I can't reproduce it, the file in question /usr/bin/steam-runtime has been replaced/edited/updated in the latest version, so it's by default, without additions and launching it with the Keyboard Shortcut I've been using for Steam for always (Meta + G), works perfectly fine, so FINALLY, it has been fixed.

Sorry for the inactivity, I've been a little busy and honestly, I was really discouraged by having to do the debugging, without having to do that, I don't mind doing the tests needed at all, or giving the info I can provide, but that was mostly what kept me from helping out more. Sorry about that. I'll try to improve that in the future by my side.

Thank you very much for finally solving it, it's taken a while, but I really see Valve is doing some hard work with Steam Deck in mind & on the horizon, which makes me really hyped. I really hope Steam will work even better when the firsts Steam Decks arrive to their owners :).