Submitted a downstream bug for Debian here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065066
Thank you. High quality bug report! It's unlikely to be an issue with Debian.
Long shot, but can you make sure you have a ~/.config/cef_user_data folder that exists and is accessible/writable by the user running steam? E.g. /home/breetai/.config/cef_user_data.
The location of that folder may be affected by your XDG_ environment variables too (XDG_CONFIG_HOME).
I have the directory ~/.config/cef_user_data and it's writable by the user.
I saw there were some symlink problems elsewhere. So maybe worth a try.
The fix was something else. I had the ~/.config/ directory as a symlink to my SSD. After removing the symlink and moving .config to the physical $HOME.
Steam starts up now on my desktop.
Thank you for giving me the correct pointers.
However, Steam did not start on my laptop running the same OS using an Intel UHD 620 GPU. Which doesn't have symlinks. After checking it seemed that the archive for Runtime Sniper wasn't extracted properly. (as seen in issue https://github.com/ValveSoftware/steam-for-linux/issues/10412) Removed the Sniper runtime directory and restarted Steam. Steam did start up on my laptop now.
I think we can close this issue now.
Ok, I also have .config and also .cache symlinked to ssd. Will try your approach and move .config to my $HOME directly
@TTimo or @kisak-valve, perhaps you could retitle this to something like "Steamwebhelper not responding when ~/.config is a symlink" to catch the main problem here? The fact that it's Debian is not the key thing here.
I had the ~/.config/ directory as a symlink to my SSD
@jhaand, where was the mount point for the SSD?
I also have .config and also .cache symlinked to ssd
@siborg, where is the mount point for your SSD?
~/.config/cef_user_data
This looks like a CEF default. @TTimo, would it be feasible to teach future releases of steamwebhelper to use a directory inside the Steam installation instead of this default? I think that would have avoided this.
As a general piece of advice for anyone experiencing an issue similar to this one, symlinks are not ideal as a mechanism for offloading sections of the filesystem to a different disk, because they are application-visible, and in particular they interfere with container technologies. Mount points and bind-mounts will be less likely to cause strange application behaviour.
Symbolic links are a particularly frequent problem for container frameworks like the Steam Linux Runtime, because merely bind-mounting $HOME into the container is not enough to get the target of the symlink into the container as well: we have to go looking for the target of the symlink. It is not feasible to search through the entire home directory for symlinks and share the target of every symlink, because that would delay Steam startup by a lot (and that approach would also involve searching through parts of the home directory that are nothing to do with Steam, which seems bad for user privacy).
If we know about specific locations that need to exist - for instance $XDG_CONFIG_HOME/cef_user_data - then those could be handled by having an increasingly long list of special cases. Again, the longer that list is, the slower it will be to start Steam, so we should try to keep this in proportion. At the moment our list includes ~/.steam and the Steam installation directory (typically ~/.local/share/Steam or ~/.steam/debian-installation), but not $XDG_CONFIG_HOME/cef_user_data.
There are some target directories that should usually work even though we don't have a special case for the symlink, because we do have a special case for the target: anything below /home, /opt, /media, /mnt, /run/media or /srv. (Full list: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/shared-paths.md?ref_type=heads#similar-to-the-home-directory)
There are also some target directories that we can't ever use for technical reasons, even if the symlink that points to them is on our list. Anything below /usr is the most notable example. (Full list: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/shared-paths.md?ref_type=heads)
Anything that is not on either of those lists, for example non-standardized mount points like /ssd or /games, will not work without special action being taken, but can be made to work with some extra effort.
ok. so after moving .config from separate ssd to $home location, steam starts and works ok thanks!
I still have .cache symlinked to separate SSD but this does not seem to have an effect on Steam.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10552#issuecomment-1972886598
I assume if I have mounted .config or .local rather than symlinking it - it should have not caused an issue?
I assume if I have mounted .config or .local rather than symlinking it - it should have not caused an issue?
That's correct. The container runtime framework uses the equivalent of mount --rbind, so it will automatically pick up any mount points below the directory we're sharing with the container.
Thanks Simon. Will keep it in mind going forward!
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10552#issuecomment-1972876881
Sounds like a good idea.
That was an absolute path to /home_fast
Right, that's a non-FHS path that won't work automatically.
The idea is to move /homes to the SSD and put the steam folder on the HDD. But I have no idea yet on how to do that cleanly without too much trouble.
What I'd recommend to minimize problems is keeping the whole of /home on SSD, including the entire Steam installation (which is relatively small when compared with modern games), but then adding a new Steam library folder on the HDD, and installing larger games into that. Those instructions talk about Windows, but the UI is basically the same on Linux. You can even make the library on HDD the default, if you want all new games to install there. On my test machines I've added ~/SteamLibrary as my main game library, but I could equally well have chosen /mnt/hdd/SteamLibrary.
Or, if you find that you absolutely need to have /home split between SSD and HDD, I would recommend using bind mounts in preference to symlinks. For instance, you could keep most of /home on SSD, but with bind-mounts for large directories where a performance hit is acceptable, so for example your /etc/fstab might contain something like:
/mnt/hdd/breetai/Music /home/breetai/Music none bind 0 0
/mnt/hdd/breetai/SteamLibrary /home/breetai/SteamLibrary none bind 0 0
/mnt/hdd/breetai/Videos /home/breetai/Videos none bind 0 0
and that will be more reliable than using symbolic links like /home/breetai/Music -> /mnt/hdd/breetai/Music.
Or conversely, if most of /home is on HDD but you want an individual directory like /home/breetai/.config to be on SSD, instead of a symlink /home/breetai/.config -> /home_fast/breetai/.config it would be more reliable to have a bind mount like:
/home_fast/breetai/.config /home/breetai/.config none bind 0 0
Okay so turns out my crash was same reason due to symlinked ~/.config to /fasthome/*/.config
running STEAM_COMPAT_MOUNTS=/fasthome steam makes Steam work fine.
I have $HOME split between /home and /fasthome but seems only ~/.config causes crash. Anyway it's still bug because log file doesn't indicate anything about Steam trying to look for /fasthome which it should say as then it would make it more clear whats wrong.
Long shot, but can you make sure you have a
~/.config/cef_user_datafolder that exists and is accessible/writable by the user running steam? E.g./home/breetai/.config/cef_user_data.The location of that folder may be affected by your XDG_ environment variables too (XDG_CONFIG_HOME).
I think I can see how to make this more robust against symlink weirdness. That's now tracked as steamrt/tasks#411 internally.
log file doesn't indicate anything about Steam trying to look for /fasthome
The container runtime framework cannot solve this part, so that would be a request for steamwebhelper or CEF: "should log something useful if it tries and fails to dereference a dangling symlink at ~/.config or ~/.config/cef_user_data". Unfortunately, the code that uses ~/.config/cef_user_data is probably buried somewhere inside CEF.
Since we got most issues under control and identified, I will close this issue.
The steam beta client is now more robust to these symlink setups.
The steam client is getting worse and worse. Things break like this. Also starting to get bloaded a lot. Please keep the client small and simple.
In my case, there was two unknown symlinks in my $home folder, there were .steampath and .steampid. I just remove it and restart Steam and it starts working.
OS: Arch Linux 6.10.9
Since there's no issue yet submitted for Debian systems with the Steamwebhelper problem, here a new issue report.
Your system information
Please describe your issue in as much detail as possible:
When starting up Steam, the client does not startup. I get a dialog with "Steamwebhelper is not responding" with different option to restart Steam. Not one of these options does start Steam.
Steps for reproducing this issue:
steam -consoleBackground information:
Digging deeper see some problems with libcef.so and a core dump.
Console log:
Output from /var/log/syslog: