Steamwebhelper is not responding: steam-runtime-sniper.tar.xz not fully unpacked #10412
Comments
|
Same here with Fedora 39, X11 with NVIDIA 535.154.05 proprietary driver. I've got the exact edit: the issued Vulkan error code -3 corresponds to |
|
Same issue, PopOS, 6.6.6-76060606-generic. I'm using an AMD CPU and GPU. Flatpak doesn't work due to the various SSD's I use not being accessible through flatpak. I ran the |
|
@Exzou Yeah, thankfully the
|
|
Can confirm. I can also see a lot of coredumps through #781 (comment) |
|
Can confirm over here |
|
Hmm, seems like its caused by something input method related... not sure why but Steam client launches normally after I unset
However I'm not able to get Fcitx5 (input method) working...
|
|
I think there might be several different things causing this same symptom, and if we let those stay as the same issue report, it quickly becomes really confusing. Let's treat whatever is happening to @Arcitec as the canonical description of this issue, and break out the other ones into separate issues if there are identifiable differences. A very major difference in the beta's steamwebhelper is that it now runs in the same environment as the Have games that run in the Steam container runtimes (Counter-Strike 2, recent Dota 2, Endless Sky, Retroarch, any Windows game via Proton 5.13+) worked correctly for you in the past? What version of Flatpak are you using? Since you mention your OS is Fedora, I assume it's a reasonably recent one. If you launch the beta, let it fail, then look in I'll ask for some more information/logs in a subsequent comment, but I'll need to get the beta running under Flatpak myself first. |
|
Because you mentioned
The error messages from this might be relevant - but they also might not, because the new version of |
|
@Guanran928, please could you open your own, separate issue, and make sure to mention [edited to add: Also, because you have |
Out of that list, the only thing I use is Windows games. I use Proton Experimental + Proton 8 + GE-Proton8 (most recent) and they have always worked.
I'll try it on their computer again to look at that. |
|
@smcv Okay the tests at the family computer are done. I enabled Beta on their computer again and it crashed.
Contents of the directory on the broken Fedora 38 installation: Contents of the directory on the working Fedora 39 installation on my own computer: Both Steam installations were made on the same Fedora version (38) and have been kept up-to-date over time via Flatpak updates and Steam's own internal updater. Because this problem is in the So this suggests that somewhere, something in Steam's own update process or code has clearly failed to install (or deleted) important files on the broken computer. Maybe it would be possible to add a startup sanity check to Steam's code which restores the missing files. |
Yes, this is clearly incomplete. During a previous run of Steam, the Reading the scripts, I can't immediately see how this failure mode is possible - it looks as though they unpack the whole thing into a temporary location before creating the The good news is that deleting the For non-Flatpak Steam, it would be
That's certainly possible, but the harder part would be to make it reliably catch all errors, without delaying every Steam startup by up to 30 seconds, which you probably don't want either. It can take that long to check that everything in the container runtime is as it should be, particularly on slower HDD-based systems. Some sort of compromise might be possible, like re-validating (or just deleting) the container runtime after
On both of your computers, and in particular the affected/broken one? The reason I ask this is because Proton >= 5.13 uses the same container runtime framework that is now being used for the Proton GE is not supported by Valve, but I believe recent versions of it are using the same container runtime framework as official/supported Proton releases. |
|
@micb25, @Exzou, @asdfjkluiop: Please could you check whether you have an incomplete For most installation methods (.deb, .rpm, Arch, NixOS ...) there is a symlink at If you installed Steam as a Flatpak app from Flathub, your top-level Steam directory will be If you installed Steam as a Snap app from Canonical's app store (not recommended) there will be a symbolic link at Even after opting out from the beta, I think the If you have the same failure mode seen by @Arcitec then it might be smaller, or might be obviously missing some files. Future betas will have a built-in way to validate that its contents are all there, but unfortunately the runtime version used in the current beta is slightly too old to have that feature. If the problem you are seeing is not obviously the same as what @Arcitec had, then please switch back to the beta. If it is still failing for you, please collect |
|
Thank you @smcv. I am very impressed with your professionalism and intelligence and the whole way you're handling this. Going above and beyond in tracking this down!
I can confirm that I saw it creating At first I would say "maybe Valve just accidentally published a broken My guess would be that tar somehow crashed while processing the archive once. And that the script somehow interpreted it as "DONE" and renamed the I can recommend using It's a nice flag since it still allows errors if you check for them, so
Thanks, that is indeed the fix for this.
I did not see it fetching any new That means I'd more likely suspect that the script was the failure, not the archive file itself. Either the script didn't validate the result, or something killed The disk has a few hundred gigabytes of free space, so I am sure it didn't stop due to that, at least.
I just had a look in that runtime directory and see that it's "2188 directories, 15520 files" so I certainly see what you mean. It's a bit more than I expected and would take a long time to verify at every startup. I agree with your ideas and think the best solution for "error recovery" would be one of the following things:
That's on both computers. They use a mixture of runtimes for each different game, but particularly Proton Experimental and GE-Proton. And the games have all worked. Strange, huh? Well, the issue happened 2 days ago, so I guess we didn't have any time to test games in the beta / sniper runtime. We reverted back to non-beta on the same day, and I guess that means the older soldier runtime is used on that computer again. Either way, I checked and she hasn't launched any Steam games after Jan 15th, which was 5 days before this broken beta update happened.
I can confirm. Sniper still exists when switching back to the stable Steam version, and here's the size of it:
There might be more files missing in her Steam folder though. When I "fixed" the Sniper runtime, she could start Steam Beta. But her "Steam Settings: Account" tab looks like this. I tried the same tab on my own computer with Steam Beta and the content looks correct for me. It looks like it's using an embedded web view. But she is able to browse to Store pages and Community pages with hers on Beta though. So it's not an app-wide "web view failure".
She's back on the stable version of Steam now, which doesn't have any visible issues. If there's any other issues in the future, I'll just backup her I really don't know how this system broke. Nothing makes sense. It might have been due to one of my theories above, but I think we'll never know for sure. So I guess the best Steam can do is a review of the installation script robustness, and an easier runtime recovery option in the crash window. |
I would recommend that too, but the scripts that are relevant to this issue are already doing that, so this presumably can't be the problem :-) We do know that
That's the only way I can see for the observed symptoms to happen - but it really shouldn't have happened, because if tar fails gracefully (like it would if your disk was full), or if it's killed by a signal (like if there's a segfault or if you use
The Steam client itself checks the size (but not content) of the (Yes, tar-in-zip is an odd way to distribute this, but there are behind-the-scenes reasons. Some of this might change around later in this beta cycle, but at the moment the priority is making it work at all, rather than making it efficient.)
I did wonder whether to ask you that, but if that had been the problem, then
At the moment the sniper runtime that is used as a compatibility tool for newer games and Proton versions (CS2, Dota 2, Proton 8+) and the sniper runtime that is used for The problem you had was with the It would be more space-efficient if we could use the same copy of sniper for both purposes, but there are technical problems with downloading from Steampipe before the user interface is available, and
This looks like a problem with the actual web content rather than with starting the
Yes, basically all of the Steam UI is web views (hence |
|
@kisak-valve, would you mind renaming this issue to reflect what we have diagnosed from @Arcitec and distinguish it from other reasons why steamwebhelper might be broken? Perhaps something like: If other commenters find that they have the same root cause as described in #10412 (comment), then they are reporting this issue and are in-scope here. If they find that they are getting the same symptom for a different reason, we should try to take that to a separate issue report. Thanks! |
kisak-valve
changed the title
@smcv, thanks for all your help. I have uploaded my log files here. The only suspicious thing I can spot is |
|
@micb25: Your steamwebhelper crash does not look related to the one initially reported here, so please report it as a separate issue. Unfortunately, I can't find anything obvious in your logs to distinguish it from other root causes for the same symptom. If you watch the contents of A Steam developer might be able to get something interesting from the crash dump that Steam uploaded for you, I agree that the Vulkan/EGL/ANGLE error seems to be scary-looking but harmless. I get that too, on an Nvidia test system (Ubuntu 22.04, if that matters) where the steamwebhelper is working correctly. [edited to add]
That indicates an incorrect system setup (it is wrong for
That sounds complete, so, not the original failure mode seen here.
This is also a useful diagnostic step that confirms that |
Thanks for the overview. I am completely stumped how this could have happened then. Since the script already checks the checksum of the downloaded archive many times, before and after extraction, and We can rule out disk space, power outages, sigkill, crashed processes etc, since all of those should have resulted in There are therefore only three things I can think of:
All we know for sure now is that deleting the broken Sniper runtime folder triggered a new unpacking (which may have downloaded a newer, fixed tar file from the CDN?). |
|
@smcv sorry for the delayed reply. I don't even have a steam-runtime-sniper folder in |
Yes, me too :-( The only theory I have come up with so far is that you might somehow have had more than one If you want to see whether you can spot something that I've missed, the relevant scripts are
In theory it's possible, but I doubt it? At the time of writing, I'm reasonably sure there has only been one version of this distributed to the public so far, which is the initial one that most users are unpacking successfully. The next big update in the beta channel will probably catch it up to the same version that's in the beta branch of
I've tried truncating the archive, and Steam is able to recover. It can't start its main UI, but it can start enough modules to verify file sizes and re-download.
It shouldn't be possible, but perhaps there's a logic error I'm not seeing?
No, for simplicity
Yes. The point of no return is when it renames
Without logs/output, we can't tell whether it downloaded anything from the CDN or not, but if your tar file was intact, then deleting the broken unpack directory should have just triggered a new unpack, without needing to re-download anything. |
OK, this is weird. The next time you start Steam, it should automatically recover from this by deleting I don't know what's happening on your system (please look for logs, especially |
|
For me the problem is not related to the sniper runtime. |
|
@MastaG: You have a similar symptom, but for an entirely different reason. Please open a separate issue, and make its title as specific to your situation as possible, for example perhaps "steamwebhelper beta not starting under Flatpak: Failed to execute child process "dbus-launch". I have confirmed that steamwebhelper does normally work correctly under Flatpak, so there must be something specific to your system that is making it fail in this way. It looks as though Steam is not receiving the Please try launching Steam as: This will put a lot more information in [edited to add] Since the recent beta, running Steam under Flatpak requires a D-Bus session bus with the When running Steam un-sandboxed, a D-Bus session bus is strongly recommended but not strictly required: it's only when it has been installed as a Flatpak app that the D-Bus session bus is a functional requirement. |
|
@smcv well I don't know what happened. I switched back to beta to gather the logs and the beta now works just fine. Was there an update? I had switched back and forth between stable and beta several times while debugging this and it always broke the same way, few days later and it's fixed now |
There has been at least one update to the container runtime (the most visible part of that is that there's now a progress bar shown while it's being unpacked), and there have probably also been updates to It seems that this works most of the time for most people, but not always. With the information available here, I can't tell what happened to you more precisely - it might have been the same root cause as the original issue report here, or it might have been more like #10431, or something different. If the Steam beta continues to work for you, then it will not be possible to diagnose what happened, so we will have to dismiss this as "you were unlucky". If it fails again in a similar way in future, please try to collect logs, then report the issue with full details, and we can try to figure out what is going on from there. |
|
deleting all the steam When running it from the terminal you can see what it creates and then delete the runtime files. |
|
@CaptainMorgan12: Are you sure you mean This issue report is about the beta client, which has stopped using the But, if you're using the stable (non-beta) client, perhaps there is some older bug where We don't understand how this "half unpacked" situation can happen, so any logs you can provide of the failing scenario from |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
There are several situations that can cause the steamwebhelper not to work: some of them are related to the sniper runtime, and some are not. For this specific issue report, the only one that is in-scope is if there are signs of For anyone else who is experiencing the "Steamwebhelper is not responding" dialog, please check the Steam logs for more information (Flatpak users: If your symptoms and logs match symptoms and logs seen by other users, you can subscribe to an existing bug report without adding comments by using the "Notifications" panel. You can help us to solve bugs more quickly by only replying if you have new information. |
Just wanted to say thanks. I've been experiencing this issue and this fixed it. There were two runtimes in that folder (heavy and sniper). I deleted them both, steam re-unpacked sniper and it worked again. |
This comment was marked as off-topic.
This comment was marked as off-topic.
thanks, man although in my case, only deleting resulted in the same problem; the pop up with progress bar extracting the txz exiting too soon. i manually extracted it to steam-runtime-sniper and its working now. |
|
I was just having the same problem, but I'm not using the beta client, and I'm on linux Ubuntu 22.04. I'm also only using the Valve-recommended steam_latest.deb file and apt to install it. I'm not using flatpak or snap. What appears to have caused it for me was that I had just updated my mesa video drivers, from When I rebooted steam would show itself in taskbar and report that everything was working in the output in the bash shell, but the steamwebhelper application kept freezing with that popup message. I purged all the mesa drivers and tried steam, and the error continued. I reinstalled steam and the error continued I removed steam with apt and then manually searched my drive for anything containing the word "steam" but that seemed related to "code files" such as JSON or Python or Lua, etc, and I deleted everything except several image files (which I'm not sure if they were associated with steam) and deleted all the folders, and everything in the folders (except the common folder, which I copied somewhere else). There are in fact a lot of files left behind after an uninstall... I used APT to reinstall the packages that steam originally installed as dependencies or otherwise used apt autoremove to remove them, and then I reinstalled steam again. This time it seemed to do a more clean "reinstall" as it told me it had several dependencies that it needed to install, again, (just like the first time). This was a good sign to me. I tried deleting the steam-runtime-sniper folder, as you suggested (which is probably unnecessary as I deleted everything steam just before) After all that, the problem persisted, but I didn't get the "steamwebhelper has stopped responding" error anymore. Steam just didn't show in the taskbar and wasn't visible, but reported itself as already running. I tried several times to kill and reopen it, but it kept-on this way; the error kept happening the same way... Finally I figured I'd just try putting the "sudo add-apt-repository ppa:oibaf/graphics-drivers" mesa drivers back on Directions here, only I used vulkan-tools instead of vulkan-utils, I guess the package name changed since the directions were written..., and installed vulkan and VDPAU VAAPI, etc, all the mesa stuff. Did the update/upgrade step with apt, and after doing that, lo-and-behold the steam UI would show up after-all. I still haven't tested if the games are working as I'm still in the process of copying the common folder... I'm fairly confident this portion will go smoothly now that the primary steam application appears to be working again and I was able to log back in with it. [Update] So I hope that helps you and I hope you don't go through the same trouble I did... [Update 2] |
It seems that you had a similar symptom, but for different reasons involving swapping between graphics drivers. That is not this issue. There are several situations that can cause the steamwebhelper not to work: some of them are related to the sniper runtime, and some are not. For this specific issue report, the only one that is in-scope is if there are signs of |
just wanted to say this comment was helpful for me. i had a shutdown while updating steam so the sniper-whatever was incomplete. only difference, my sniper steam directory by default was /home/.steam/debian-installation/ubuntu12_64/steam-runtime-sniper thanks. |
Your system information
Please describe your issue in as much detail as possible:
Steam doesn't open. Error message below appears on every startup. Attempting to restart "without GPU Acceleration" doesn't work. When starting steam with the terminal via
flatpak run com.valvesoftware.Steam, I can see that it attempts to start steamwebhelper 6 times and that each one crashes.This issue appeared in the January 20th, 2024 update of Steam Beta for Linux.
Steps for reproducing this issue:
Steps for fixing this issue:
ps aux | grep -i steam.flatpak run com.valvesoftware.Steam -clearbetawhich will tell Steam to delete the beta, and it will automatically go back to the stable release channel. (edit: People who use the native Steam packages instead should runsteam -clearbetainstead.)The text was updated successfully, but these errors were encountered: