It's unclear whether this is a problem with steamwebhelper itself, or a problem with the container environment that it runs in.

To confirm which one it is, please try running Steam as:

STEAM_LINUX_RUNTIME_VERBOSE=1 steam

then provide your ~/.steam/steam/logs/webhelper-linux.txt as a Gist or attachment. It will be much larger than the one that was included in your steam-logs.tar.gz.

It will contain environment variables, so if you have any environment variables with secret content (GITHUB_TOKEN or similar), please censor them by replacing their values with a placeholder like xxxx.

Here it is:
webhelper-linux.txt

Thanks, that's useful.

It just stops there? That seems strange: your log ends halfway through setting up the container runtime. Most of the time when there's a problem with this component, it's something crashing and being restarted - but in your case, it looks more like something has got stuck.

It might be helpful to run Steam as

SRT_LOG=timestamp STEAM_LINUX_RUNTIME_VERBOSE=1 steam

which would put timestamps on the log messages, giving us a better idea of how long things are taking.

If you leave it in that state for some time (5 minutes should be enough) and look at the log again, has anything new been logged?

Do you get the "Steamwebhelper is not responding" error message appearing? If you do, please try selecting "Restart steamwebhelper", "OK", then wait a few minutes and retrieve the log again. If the log becomes large, we might need to see webhelper-linux.previous.txt as well.

Does your system setup involve any unusual filesystems like NFS, SMB, NTFS, overlays, autofs, that sort of thing?

@kisak-valve or @Odeylo-git, please could you rename this issue so it doesn't attract replies from users who are seeing a crash with different symptoms? Perhaps something like Steam crashes after steamwebhelper container setup gets stuck.

At 17:48 I disabled the VPN, but that didn't change anything.

"Steamwebhelper not responding" appeared, but after restarting it just hung until I pkill'ed steam and steam-runtime.
Restart was at 17:54

webhelper log

And here's what it showed me in terminal: term log

I have an ntfs drive but it is unmounted, the main system is on ext4 nvme.

Huh. It does seem like the container runtime setup is just ... stopping; and at a predictable time, too.

I think the next step would be to find out exactly what it thinks it's doing at the point where it stops, but to be able to do that, we'll have to prepare an instrumented version of pressure-vessel with extra debug messages.

I have an ntfs drive but it is unmounted, the main system is on ext4 nvme

Good - the situation I was trying to rule out was something like "it gets stuck when it tries to access a file on a non-working NFS server halfway around the world" and it seems that you don't have that :-)

One thing that you can find out without needing a special pressure-vessel build is: when Steam is in this stuck state, is there a pressure-vessel-wrap process using a lot of CPU time, or is it idle?

Another useful piece of information would be: find a directory with a name that looks like /home/Odeylo/.local/share/Steam/ubuntu12_64/steam-runtime-sniper/var/tmp-XXXXXX (the XXXXXX will be something different, but hopefully there should only be one directory like this). cd into it, then try running:

cd usr/lib/pressure-vessel/overrides
find -ls

Some time ago

Do you have any idea how long ago?

Am I correct to think that before that time, Steam was working well for you?

Depending on what's causing this, the regression might be linked to a Steam update, or it might be linked to something you upgraded or changed on your system, such as glibc or the kernel.

You gave me the idea that maybe the problem is in the packages, but because neither pacman nor yay showed updates even with -yy, I decided to completely reinstall all the packages via yay -Qq | yay -S - and it worked. I honestly don't know what was wrong and why reinstalling everything helped...
Thanks for your help!

Very strange...

Because you can no longer reproduce the problem, I think we'll have to assume that this was a bug in some OS component that doesn't require action in the container runtime, unless/until someone else encounters a similar issue.

Note to other issue reporters: if you encounter similar symptoms, please open a new issue with details of your system and logs, instead of replying to this one - but it would be useful to mention "perhaps the same as #11160" in your new issue report, and it would also be useful if you can start by trying some of the debugging steps described here.