Hello @peacememories, can you check if this is the same issue as discussed on #9383?
I have the same problem, since the last update it doesn't work well.
I tried uninstalling and purging ~/.steam/ ~/.steampath ~/.steampid but the problem persists
Your system information
Steam client version (build number or date): 1714854927
Distribution (e.g. Ubuntu): Debian GNU/Linux 12 (bookworm) (64 bit)
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Steam Logs: logs.zip
GPU: Radeon Vega 6
Same issue. I also reported another issue which seems pretty much the same thing (The behaviour is the same - really long dealys till it somehow seems to "refresh" itself). See https://github.com/ValveSoftware/steam-for-linux/issues/10853 I think the issue with the start might be related to that small popup that sometimes shows up when starting steam to inform you about new offers/releases.
I checked he issue kisak-valve shows but i don't have a igpu since this is on 5700x3d / Rx7700 XT
I had a similar issue, started last tuesday for me. I guess when Steam had their last maintenance. When trying to open with the icon, the steam logo would show up in the task tray. But the main window wouldn't show up. I was able to still launch games by clicking the icon in the task tray though.
I then tried to run steam with sudo from the terminal. It did some update and the steam store actually came up this time. I thought I had resolved the issue, but trying to launch steam normally still resulted in the same behavior as before
I have the same issue with extremely stupidly long startup times (15 ****ing minutes on [email protected] 64GB DDR4 4x2TB NVMe RAID0, so it's NOT my ****). I've resorted to starting steam in a shell and spamming Ctrl+C sporadically terminating crap in the background it attempts to launch, it can speed up my startup times. Do it enough and you'll notice patterns around that plagueware of Chromium underneath and the entire websocket garbage. Edit: I despise this new UI so much. I miss the old Steam UI, functional and fast (aside from DPI issues and rasterized images). My frustration with this stems from a year of this expecting better but getting the same no-dpi-slider crap.
Steam Version: 1715635533
Distro: Manjaro KDE (64 bit) Wayland
GPU: RX 5700 XT x 2
I faced the same issue today. Steam's tray icon and the corresponding menu is in the system tray. But the window does not open. A curious workaround is disabling the internet connection before launching Steam. The window opens as usual this way without delay.
I faced the same issue today. Steam's tray icon and the corresponding menu is in the system tray. But the window does not open. A curious workaround is disabling the internet connection before launching Steam. The window opens as usual this way without delay.
I think that the issue on my side may not be related to internet services. Having my xbox joystick plugged is what is actually making Steam's window to not be shown. Weird...
I am seeing a similar problem (on Arch). Checking the logs, I see the following in webhelper.txt:
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: websocket connect retry: limit exceeeded, bailing - steamUI
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to re-connect to websocket after close
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: OnWebsocketReconnect: Failed to reconnect to steam client
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: websocket connect retry: limit exceeeded, bailing - clientdll
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to re-connect to websocket after close
[2024-05-18 00:47:06] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: OnWebsocketReconnect: Failed to reconnect to steam client
[2024-05-18 00:47:07] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:07] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
[2024-05-18 00:47:07] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:07] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
The following part keeps repeating every couple of seconds:
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-05-18 00:47:09] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10879#issuecomment-2118464430
Same but Manjaro, my webhelper is filled with entries alike.
Edit: My DNS server protects clients by preventing DNS rebind (removes any local-addresses from DNS records, reports NX for domains). I added it to the allowlist, no change in Steam's behavior.
Edit: Steam isn't listening on 443, so I'm wondering how it's trying to capture that loopback. 443 is a privileged port anyway (<=1024), regular processes wouldn't be able to open it anyway.
Edit: Adding CAP_NET_BIND_SERVICE to steamwebhelper and steam (purely for the sake of testing) had no effect, not to mention steam isn't a binary.
Edit: This is also what causes games such as HMCC to hitch terribly keeping the FPS to maybe 1 frame per 30 seconds (HMCC calls some Steam APIs constantly in a blocking mode, made evident by patching steam_api to circumvent to test and suddenly vsync and fine).
Edit: A little poking around, this looks like IPC behavior. Chromium (the @!*%ty underneath of Steam's UI since they ruined it) uses IPC like this and it's just awful.
Hello @peacememories, can you check if this is the same issue as discussed on #9383?
DRI_PRIME is not set on my machine, which makes sense since it's a desktop with only one, dedicated, GPU (the 5800x3d does not even have an IGP)
This happens to me too, also tested with the flatpak version and steam-runtime.
Steam client version (build number or date): 1716584667
Distribution (e.g. Ubuntu): Arch Linux
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Steam Logs: -
GPU: AMD Radeon 7900 XTX
To help establish how long this issue has existed...it's been this way since the UI revamp. That long. -_- I've figured out that starting Steam in a shell and then waiting until after it initializes Vulkan to constantly spam Ctrl+C helps. Each call to the CEF's IPC like that needs a Ctrl+C. I can select a new game and wait ages for it to "load" the library details or I can alt-tab and Ctrl+C the shell and the library details instantly load. @!Q# Chrome/Chromium and CEF. This 'web browser as software' ^%#* should be outlawed. Edit: The Ctrl+C technique works for nearly everything, even for right-clicking the Steam icon to exit. Right-click and wait forever or right-click, alt-tab to the shell and Ctrl+C, bam instant menu. It even helps Steam shut down faster.
I tried setting ip_unprivileged_port_start to 1 (just for testing), no go. Steam doesn't open 443 and I disabled httpd beforehand so nothing would be bound or listening on 443, but no go. This loopback way of doing stuff is broken.
@OdinVex Interestingly enough, Steam works just fine on my laptop with an almost identical Arch installation. I wasn't able to isolate anything yet though.
Also experiencing this issue on EndevourOS, Steam takes over a minute to launch, CS2 is unplayable with massive frame rate drops every few seconds. I collected logs based on this request, which seems to be relevant to this issue.
Logs & System information: Gist
It looks like steam generated a dump file at launch, if that is useful I can upload it.
After spending some minutes staring at lsof output, I realized Steam was somehow using my work-related loopback hostnames I had defined in /etc/hosts. After I removed those, the issue went away as well as other Big Picture issues including the startup intro being transparent and the escape menu not working.
After spending some minutes staring at
lsofoutput, I realized Steam was somehow using my work-related loopback hostnames I had defined in/etc/hosts. After I removed those, the issue went away as well as other Big Picture issues including the startup intro being transparent and the escape menu not working.
Nothing funky in my /etc/hosts. Shouldn't matter anyway so long as none are 'steamloopback.host'. Issue still exists.
I've further narrowed it down to Steam having problems with loopback hostnames containing hyphens. By appending /etc/hosts with:
127.0.0.1 te-st
I've been able to reproduce the issue on previously unaffected machines. Replacing te-st with test makes Steam work well again.
@OdinVex try to run lsof -c steam while Steam is running and watch out for similar lines:
steam 359053 USER 42u IPv4 2732420 0t0 TCP te-st:57343 (LISTEN)
I've further narrowed it down to Steam having problems with loopback hostnames containing hyphens. By appending
/etc/hostswith:127.0.0.1 te-st
Valid host names are a-z9-0 and -. If CEF/Steam has an issue with that then Steam is the problem. I use IPv6, so there's no way I can remove the IPv6 loopbacks. I'm not going to, either. CEF needs to go. Steam should just use something cross-platform like Qt.
Edit: To hammer this home:
# Standard host addresses
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
These are stock, minimal entries when using IPv6. It's going to have dashes because it's valid.
Edit: This also an older hosts file. Newer ones (depending upon distro) have even more dash-containing entries. Note: https://gist.github.com/ghoneycutt/e531984406b4b86ace687ea8958a6dc3
Edit: lsof -c steam didn't provide anything useful on my end, just perfectly valid DNS:
steam 36796 <REMOVED> 42u IPv4 116630 0t0 TCP localhost:57343 (LISTEN)
steam 36796 <REMOVED> 45u IPv4 151016 0t0 TCP localhost:55613 (LISTEN)
steam 36796 <REMOVED> 74u IPv4 116638 0t0 TCP localhost:27060 (LISTEN)
steam 36796 <REMOVED> 75u IPv6 136738 0t0 TCP <REMOVED>.local:50531->[2602:801:f002:101::a2fe:c00e]:http (ESTABLISHED)
steam 36796 <REMOVED> 76u IPv4 136650 0t0 TCP <REMOVED>.local:63995->a23-48-99-150.deploy.static.akamaitechnologies.com:http (ESTABLISHED)
steam 36796 <REMOVED> 77u IPv4 152929 0t0 TCP localhost:52999 (LISTEN)
steam 36796 <REMOVED> 107u IPv4 121601 0t0 TCP localhost:52999->localhost:55716 (ESTABLISHED)
steam 36796 <REMOVED> 108u IPv4 116686 0t0 TCP <REMOVED>.local:62239->a23-210-138-105.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
steam 36796 <REMOVED> 109u IPv4 153863 0t0 TCP <REMOVED>.local:57637->162-254-199-181.valve.net:27031 (ESTABLISHED)
steam 36796 <REMOVED> 110u IPv4 134575 0t0 TCP localhost:55613->localhost:59616 (ESTABLISHED)
steam 36796 <REMOVED> 112u IPv4 153860 0t0 TCP <REMOVED>.local:56697->162-254-199-163.valve.net:27035 (ESTABLISHED)
steam 36796 <REMOVED> 115u IPv4 153861 0t0 TCP <REMOVED>.local:64847->162-254-199-163.valve.net:https (ESTABLISHED)
steam 36796 <REMOVED> 116u IPv4 121598 0t0 TCP localhost:52999->localhost:51848 (ESTABLISHED)
steam 36796 <REMOVED> 117u IPv4 134573 0t0 TCP localhost:55613->localhost:61278 (ESTABLISHED)
steamwebh 37141 <REMOVED> 28u IPv4 159849 0t0 TCP localhost:51848->localhost:52999 (ESTABLISHED)
steamwebh 37141 <REMOVED> 29u IPv4 159851 0t0 TCP localhost:61278->localhost:55613 (ESTABLISHED)
steamwebh 37141 <REMOVED> 31u IPv4 145628 0t0 TCP localhost:59616->localhost:55613 (ESTABLISHED)
steamwebh 37141 <REMOVED> 34u IPv4 145629 0t0 TCP localhost:55716->localhost:52999 (ESTABLISHED)
Edit: Interestingly enough, lsof does seem to pause for quite a while just before it displays a first TCP entry for any software.
Edit: Removed all entries except host name (has no dashes) and localhost, no change, still crap performance.
Arch Linux, up-to-date.
Adding a +1 to Steam not handling hyphenated hostnames. I've been experiencing the same startup patten described here. My hostfile looked exactly like this (EAC Workaround provided by https://github.com/starcitizen-lug/lug-helper for Star Citizen)
# Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1 modules-cdn.eac-prod.on.epicgames.com #Star Citizen EAC workaround
Added a # to comment out the EAC line and Steam starts right away.
A Steam friend of mine that does not experience this bug and is on Arch-based distro like me sent me their hosts file, contains dashes. Dunno why some people would have issues and others wouldn't. I removed all dashes, problem still exists. They have dashes, no issue. (Edit: In short, I don't think it's dash-related. Maybe lookup-related or something, but not particularly about dashes.)
Gentoo here. Removing dashes from /etc/hosts fixes the issue for me too. I also noticed that the "Waiting for network...", "Logging in..." and "Loading user data..." screens only show up after removing the dashes in /etc/hosts.
For anyone else having this issue that uses external DNS (eg. no system caching because caching can be problematic or for DNS sinkholing to protect your systems/networks) you've probably disabled the $*%&show that is systemd-resolved and have NetworkManager alone doing its thing. Even though getaddrinfo will work correctly...Steam won't. You'll have to re-enable the freakshow systemd-resolved. My guess, Steam or something it depends upon reads resolv.conf directly instead of obeying. See https://wiki.archlinux.org/title/Systemd-resolved#DNS for more details. (Edit: I won't use ResolveD, has no business existing.)
I'm not running systemd-resolved on any of my systems but my laptop (same OS as my main machine) does not exhibit the slow startup/reaction time of steam. I experimented with the NSS config of my main machine, and going from mdns to mdns_minimal seems to have resolved the slow down on that specific machine.
I'm not running systemd-resolved on any of my systems but my laptop (same OS as my main machine) does not exhibit the slow startup/reaction time of steam. I experimented with the NSS config of my main machine, and going from
mdnstomdns_minimalseems to have resolved the slow down on that specific machine.
Interesting. I disabled systemd-resolved and switched to minimal, working.
same erros using crossover 24 on macos, tried wineskin, whisky and vanilla wine, everything with same results....
==> /Users/diego/Library/Application Support/CrossOver/Bottles/Steam-2/drive_c/Program Files (x86)/Steam/logs/webhelper.txt <==
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: websocket error
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: failed to reach open state
[2024-06-24 19:24:56] SP Shared JS Context-'SharedJSCo': WARNING: https://steamloopback.host/library.js:2: connect attempt failed: 2 - failed to reach open state
I narrowed down the reason for mine a bit more, to avahi and/or mdns/_minimal combined, having nothing to do with systemd-resolved (that simply got avahi re-enabled which was a false lead on systemd-resolved):
If I disable avahi-daemon it's fine. If I enable avahi-daemon and set mdns to mdns_minimal it's fine. If I enable avahi-daemon but leave it as mdns the issue suddenly presents.
Edit: I always disable DNS caching and never have anything open on 53, I don't allow any hosts to cache DNS responses in my network, just my DNS servers do that (and they also handles mDNS). I wonder if Steam developers are assuming something about mDNS or DNS caching?
I don't think it's entirely on Steam. The only difference between mdns and mdns_minial is that mdns_minimal will only ever try to resolve .local domain names. I experimented with calling avahi directly to try to resolve steamloopback.host, which took multiple seconds to fail the first couple of times. Afterward, avahi seam to have cached the result of it not resolving and it started to fail faster.
Additionally, I tried adding an entry to /etc/avahi/hosts for steamloopback.host which seemed to have resolve the issue in a way that Steam was "fast" again with mdns instead of mdns_minimal. However, after a few restarts of Steam, it became slow again, which was only fixed by going back to mdns_minimal.
It seems to as though there is some strange interaction happening in the name resolution logic of avahi, in that it should not take seconds to conclude that a .host name does not resolve via mDNS. I have yet to scour the relevant RFCs though, so I'm not sure if trying really hard to resolve a .host name is according to spec. Something for the weekend ;)
(On a side note: I may try moving files up in the NSS stack and put an entry in there for steamloopback.host, maybe that would work too. Don't get me wrong, I'm not arguing that this would be an acceptable solution to this problem, but neither is having to fall back onto mdns_minimal)
...
Using plagueware like CEF masquerading 'web apps' as software and requiring a loopback host to begin with is the root of this issue, let alone considering some firewalls/DNS servers have options to prevent DNS rebind attacks/leaks by removing/refusing/rewriting/dropping DNS with private-IP range responses, even for 127.0.0.0/8 responses.
I want to add that after switching hosts in /etc/nsswitch.conf from mdns to mdns_minimal steam starts right up. Before then I had a large delay, and the websocket warnings.
I have the same issue with extremely stupidly long startup times (15 ****ing minutes on [email protected] 64GB DDR4 4x2TB NVMe RAID0, so it's NOT my ****). I've resorted to starting steam in a shell and spamming Ctrl+C sporadically terminating crap in the background it attempts to launch, it can speed up my startup times. Do it enough and you'll notice patterns around that plagueware of Chromium underneath and the entire websocket garbage. Edit: I despise this new UI so much. I miss the old Steam UI, functional and fast (aside from DPI issues and rasterized images). My frustration with this stems from a year of this expecting better but getting the same no-dpi-slider crap.
Steam Version: 1715635533 Distro: Manjaro KDE (64 bit) Wayland GPU: RX 5700 XT x 2
I agree. JS on the desktop is inappropriate and a technically uninformed decision.
Though, I do admire Valve for being so... determined... as to make a thoroughly bad idea work as it does and ignore all the bright-red, illuminated flags.
I wonder if Steam developers are assuming something about mDNS or DNS caching?
Apparently, assumptions abound. It seems nobody thought enough about checking return values, either.
I may try moving
filesup in the NSS stack and put an entry in there forsteamloopback.host, maybe that would work too. Don't get me wrong, I'm not arguing that this would be an acceptable solution to this problem, but neither is having to fall back ontomdns_minimal
When working knowledge disappears, workarounds become the 'fix'. It's pathetic and scary how commercial software is produced.
Interesting. I disabled systemd-resolved and switched to minimal, working.
If you have to reconfigure your system and network because of someone else's ignorant oversight, something has gone very wrong with both software development AND troubleshooting.
Appendix: OK, so... the host name steamloopback.host resolves to 127.0.0.1...
So, just in case I am missing something isn't 127.0.0.1/8 a standard IP address in the TCP/IP stack of, like, EVERY computer in existence??? Did Valve have to use another DNS record to point to 127.0.0.1 instead of simply using 127.0.0.1... Anyone else think they've walked around the block to go upstairs?
@another-username2, Preach brother!
I've updated the Arch Wiki's Steam troubleshooting subsection to reflect this issue. https://wiki.archlinux.org/title/Steam/Troubleshooting#Very_long_startup_and_slow_user_interface_response
I've further narrowed it down to Steam having problems with loopback hostnames containing hyphens. By appending
/etc/hostswith:127.0.0.1 te-stValid host names are
a-z9-0and-. If CEF/Steam has an issue with that then Steam is the problem. I use IPv6, so there's no way I can remove the IPv6 loopbacks. I'm not going to, either. CEF needs to go. Steam should just use something cross-platform like Qt.
Im speechless thats just unprofessional
Im speechless thats just unprofessional
No one's paying us to debug Steam's problems. CEF itself is unprofessional. Masquerading a 'web app' as a desktop software is an unprofessional cop-out, especially since it's come at everyone's expense with massive buttons and underutilized space, poor layouts and 'trending/upsell/DLC' thrown in your face with unwanted "news" and a crappy experience. Uses more RAM, more resources, slower access, list goes on. Don't bother mentioning unprofessional because this is as good as it gets for what it is.
Edit: Not to mention that undoing 35+ years of a standard for naming machines just to appease a bug? No. This should never have happened, but it did. Fine. The problem is the lack of a fix after SO damn long and THIS (Steam client) is what we're left with. That's unprofessional.
On fedora 40 affected by this problem, removing the 127.0.0.1 view-localhost in hosts helped.
I can confirm the same issue on Ubuntu 24.04. Here is console log:
steam.sh[60447]: Running Steam on ubuntu 24.04 64-bit
steam.sh[60447]: STEAM_RUNTIME is enabled automatically
setup.sh[60564]: Steam runtime environment up-to-date!
steam.sh[60447]: Steam client's requirements are satisfied
[2024-07-24 10:26:18] Startup - updater built Jul 16 2024 23:21:18
[2024-07-24 10:26:18] Startup - Steam Client launched with: '/home/user/.local/share/Steam/ubuntu12_32/steam' '-srt-logger-opened'
07/24 10:26:18 minidumps folder is set to /tmp/dumps
07/24 10:26:18 Init: Installing breakpad exception handler for appid(steam)/version(1721173382)/tid(60633)
[2024-07-24 10:26:18] Loading cached metrics from disk (/home/user/.local/share/Steam/package/steam_client_metrics.bin)
[2024-07-24 10:26:18] Using the following download hosts for Public, Realm steamglobal
[2024-07-24 10:26:18] 1. https://client-update.akamai.steamstatic.com, /, Realm 'steamglobal', weight was 1000, source = 'update_hosts_cached.vdf'
[2024-07-24 10:26:18] 2. https://cdn.cloudflare.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'update_hosts_cached.vdf'
[2024-07-24 10:26:18] 3. https://cdn.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in'
[2024-07-24 10:26:18] Verifying installation...
[2024-07-24 10:26:18] Verification complete
UpdateUI: skip show logo
Steam logging initialized: directory: /home/user/.local/share/Steam/logs
XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xe7993860
XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xe7991fc0
/usr/share/themes/Yaru-blue-dark/gtk-2.0/main.rc:775: error: unexpected identifier 'direction', expected character '}'
/usr/share/themes/Yaru-blue-dark/gtk-2.0/hacks.rc:28: error: invalid string constant "normal_entry", expected valid string constant
CAppInfoCacheReadFromDiskThread took 61 milliseconds to initialize
Steam Runtime Launch Service: starting steam-runtime-launcher-service
Steam Runtime Launch Service: steam-runtime-launcher-service is running pid 60754
bus_name=com.steampowered.PressureVessel.LaunchAlongsideSteam
BRefreshApplicationsInLibrary 1: 0ms
src/steamUI/webuitransportcontroller.cpp (206) : Failed to connect to websocket
src/steamUI/webuitransportcontroller.cpp (206) : Failed to connect to websocket
07/24 10:27:03 Init: Installing breakpad exception handler for appid(steam)/version(1721173382)/tid(60633)
assert_20240724102703_36.dmp[61589]: Uploading dump (out-of-process)
/tmp/dumps/assert_20240724102703_36.dmp
BuildCompleteAppOverviewChange: 236 apps
RegisterForAppOverview 1: 8ms
RegisterForAppOverview 2: 8ms
assert_20240724102703_36.dmp[61589]: Finished uploading minidump (out-of-process): success = yes
assert_20240724102703_36.dmp[61589]: response: CrashID=bp-c8bfd9f4-938e-4996-b10b-6909b2240724
assert_20240724102703_36.dmp[61589]: file ''/tmp/dumps/assert_20240724102703_36.dmp'', upload yes: ''CrashID=bp-c8bfd9f4-938e-4996-b10b-6909b2240724''
During launch it seems to stop after BRefreshApplicationsInLibrary 1: 0ms. After a while I get src/steamUI/webuitransportcontroller.cpp (206) : Failed to connect to websocket
On fedora 40 affected by this problem, removing the 127.0.0.1 view-localhost in hosts helped.
I can confirm this is also the case in Ubuntu 24.04. However after testing I found that changing the order of the entries in /etc/hosts and putting localhost before view-localhost fixed the issue
Confirmed this bug on a Manjaro machine with multiple hyphens in the hostname. I'm flabbergasted that this is a real thing.
Confirmed this bug on a Manjaro machine with multiple hyphens in the hostname. I'm flabbergasted that this is a real thing.
RFC952 first set a standard in 1985...and with hyphens. Something's clearly assumed and amiss. Edit: Not to say that RFC952 is in anyway applicable, just merely a factoid from ancient times that set at least some mindset of hostnaming.
Edit: If you want to chase the RFC tree, RFC5891 appears to be the latest regarding it and it permits hyphens (no consecutive or beginning, rules exist).
@kisak-valve Bumping for possible tag update such as "confirmed" or whatever to get some eyes on it?
On fedora 40 affected by this problem, removing the 127.0.0.1 view-localhost in hosts helped.
I can confirm this is also the case in Ubuntu 24.04. However after testing I found that changing the order of the entries in
/etc/hostsand putting localhost before view-localhost fixed the issue
Running Fedora 40 and this fixed the issue fore me as well.
On fedora 40 affected by this problem, removing the 127.0.0.1 view-localhost in hosts helped.
I can confirm this is also the case in Ubuntu 24.04. However after testing I found that changing the order of the entries in
/etc/hostsand putting localhost before view-localhost fixed the issueRunning Fedora 40 and this fixed the issue fore me as well.
Me too. This fixed a problem I've had for a short while. I'm almost certain this is caused by VMWare Horizon Client RPM. The RPM postinst script must be plopping this line at the top of /etc/hosts without any care whatsoever. Outrageous behavior by VMWare; completely inexcusable.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/10879#issuecomment-2301430084
No, VMware is fine to do that, it's 100% valid behavior. Dashes/hyphens are valid characters, follows RFC specifications. Hostnames are allowed to include dashes or hyphens so long as the name doesn't begin with it. Steam is at fault here for relying on moronic loopback hostname crap for its WEB client masquerading as software. As more and more firewalls/DNS servers are configured to prevent DNS rebind attacks Steam'll be forced to change the behavior anyway.
Edit: Side-note, I hate Broadcom (new owners of VMware) and haven't used VMware in years. Just pointing out VMware isn't at any fault, Steam is.
Bumping because I am also running into this issue. Switched the order of the first two lines in my /etc/hosts file and Steam fired right up. Found this issue because of a steam client beta community discussion that linked me here. Hope this gets fixed soon. That was annoying to google-fu.
Replying to [#10879 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/10879#issuecomment-2301430084)
No, VMware is fine to do that, it's 100% valid behavior. Dashes/hyphens are valid characters, follows RFC specifications.
No, that's not what I'm talking about. It's not a problem with hostname chars.
All aliases need to be on the same line in /etc/hosts. man page says "For each host a single line should be present ...". RFC 952 is referenced, but that's doesn't describe Linux's format requirements for the hosts table. I'm pointing out the fact that you can't just jam text at the top of the file and supersede ever other definition in the file; that's undefined behavior, and therefore, illegal. Also, they're trying to change the loopback alias, which is very special and treated specially by the network stack, and they know that if /etc/hosts has any lines in it, one is guaranteed to be for 172.0.0.1. So, you have to scan for that line and take extra care if you are going to modify it. Besides, what was wrong with using localhost??? You can just use that and be (nearly?) guaranteed that is what you want. That's what that name standard is there for in the first pace! Or, better yet, if you want to hard code something, just f-ing use the IP addr and skip name resolution all-together.
Fine, it's probably weird for either Steam or VMware Client to use loopback for whatever the hell they are doing that could be more sensibly done with other IPC methods. But, VMware broke not just rules, but common decency. Post-Inst scripts for client software? Give me a break.
Replying to [#10879 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/10879#issuecomment-2301430084)
All aliases need to be on the same line in
/etc/hosts. man page says "For each host a single line should be present ...".
That can be read two ways. "For each host a single line should be present" can be:
127.0.0.1 localhost
127.0.0.1 pickle-fork
127.0.0.1 herpderp
I think the assumption you're making (whether incorrectly correct or not) is that an IP address is somehow a host. It's not, it's an address. A host name...is more likely to be the host, but that's how I can read it. I can also read it with your understanding of it, so it's ambiguous to me.
I'm pointing out the fact that you can't just jam text at the top of the file and supersede ever other definition in the file
...
Besides, what was wrong with usinglocalhost??? You can just use that and be (nearly?) guaranteed that is what you want. That's what that name standard is there for in the first pace! Or, better yet, if you want to hard code something, just f-ing use the IP addr and skip name resolution all-together.
Their need for a loopback is because of their dependence on :censored:ty CEF. This is also why they can't use localhost, CEF. They need a unique name for routing in CEF. They're not trying to actually use localhost, they're trying to use CEF (Chromium Embedded Framework) like all the other :censored:ed up web front-ends masquerading as a desktop software. It needs routing that can be distinguishable from other routing but also local-only so they use an 127.0.0.0/8 IP (in this case 127.0.0.1) so that it can't be routed via IP and use steamloopback.host to differentiate it from any localhost traffic. It's mostly going to be unique enough that it won't bother any other software. .host is a bad TLD to use though, it'd an actual TLD...but that's also why Steam uses it to loopback. That's a problem for any modern DNS server with privacy settings preventing DNS rebind attacks (eg passing DNS records with a private IP such as class C types).
one is guaranteed to be for 172.0.0.1.
You meant 127.0.0.1 (or any 127.0.0.0/8), right? No, that's not a guarantee. It's considered 'proper' by assumption these days but not a guarantee. There is no mandate that localhost exist, an archaic but still-true-today thing. It's a bit weird to find systems without a localhost but they do exist and nothing at all mandates it.
Fine, it's probably weird for either Steam or VMware Client to use loopback for whatever the hell they are doing that could be more sensibly done with other IPC methods. But, VMware broke not just rules, but common decency. Post-Inst scripts for client software? Give me a break.
No, Steam and VMware are allowed to do all this and it's technically valid...there are no rules being broken, the "bug" isn't in them. However...it's a :censored:ty design for Steam to use a bunch of :censored: :censored: :censored: HTML/CSS/JS to fake being a desktop client and needing to rely on this :censored: :censored: to begin with. That's my issue with this whole :censored:. I despise the new UI and I'm itching for any alternative to the Steam UI. Anyone that can put in the effort to take Steam's monopoly and force it to legally open itself up for third-party clients so we can go back to real software and none of this 'massive button/huge font/bad DPI' web-client :censored: :censored: :censored: :censored: :censored: :censored: pretending to be software. So sick of :censored: like this.
I had to install an add-on to censor myself on GitHub. >_> Tired of warnings over sensible rants against stupid designs.
Okay, but, I'm still confident you are wrong about /etc/hosts. Perhaps I didn't quote you the best line from the man page, but it begins: "This manual page describes the format of the /etc/hosts file. This file is a simple text file that associates IP addresses with hostnames, one line per IP address." The man page is not ambiguous on this point. I understand the distinction between addrs, hosts, and host names.
The man page even suggests using 127.0.1.1 for the FQDN of local host, which is yet another valid option that VMware chose to ignore.
Now, I'm not saying what VMWare did breaks everything, but it breaks the rules and it broke some actual functionality in other programs.
Yes, I transposed digits in the first octet. That's correct.
We don't really need adjudicate this, but I still don't understand 1) what's up with CEF--I know nothing about that, happily--and what that has to do with name resolution, and 2) why VMware can't follow the GD rules and just put their pet alias on the line with all the other aliases for localhost.
But, hey, I don't mean to defend Steam devs. I'm sure what you say about Steam is also valid criticism.
Okay, but, I'm still confident you are wrong about
/etc/hosts. Perhaps I didn't quote you the best line from the man page, but it begins: "This manual page describes the format of the /etc/hosts file. This file is a simple text file that associates IP addresses with hostnames, one line per IP address." The man page is not ambiguous on this point. I understand the distinction between addrs, hosts, and host names.
That would have been a better quote the first time around, sure.
The man page even suggests using 127.0.1.1 for the FQDN of local host, which is yet another valid option that VMware chose to ignore.
Any IP address in the 127.0.0.0/8 (127.0.0.1-127.255.255.255) range would work, they're all localhost.
Now, I'm not saying what VMWare did breaks everything, but it breaks the rules and it broke some actual functionality in other programs.
Again, this is about Steam's design, not VMware. Since Broadcom bought out VMware to rip people off (going badly too, so many have switched to KVM or vbox) you'll probably have to bring it up with both Broadcom and Steam as two different issues.
We don't really need adjudicate this, but I still don't understand 1) what's up with CEF--I know nothing about that, happily--and what that has to do with name resolution, and 2) why VMware can't follow the GD rules and just put their pet alias on the line with all the other aliases for localhost.
CEF is Chromium Embedded Framework. Chrome is Google's branding of Chromium (which they also develop). CEF is a prepackaged 'all in one binary' that acts like desktop software but uses web-elements for a UI, in short a self-contained interactive web server with filesystem access playing "I'm a pretend desktop software". It uses a loopback host instead of file:/// URIs and such. You keep blaming VMware (side-note, I hate Broadcom/VMware, not intending to defend) because Steam breaks because of Steam's design. Steam chose to use CEF and a moronic loopback hostname instead of actually developing a desktop software. Reliance on the loopback host breaks resolution of the name if there is an issue resolving mdns names. The issue technically isn't in Steam but Valve's stupid to rely on CEF to begin with, it's garbage. Privacy-oriented DNS servers and firewalls are having to create exceptions for Steam's stupid loopback hostname because filtering out rebind-attacks would break Steam.
I'm blaming VMware because they added an invalid line to /etc/hosts, and that broke things. There may very well be a separate, additional issue.
I don't understand your problem with loopback. That method of IPC has been around, like, for 40 years at least? It's hardly unusual to talk to yourself over loopback. What's "moronic" is requiring a private alias to tell you what is the loopback addr.
Besides, I brought up the loopback space only because you brought it up. The hosts rules could have been respected if VMWare had just chosen a unique addr; then they could have added the line--TO THE END OF THE FILE, NOT THE BEGINNING!--and everything would have worked out. And wouldn't that have been better for routing, too? It's a whole Class A go work with! Why not make you own "localhost subnet"? I still don't see what this has to do with mdns or resolution. I mean, IP routing happens at the IP layer; there are no names in routing. But, as I say, CEF is new to me. (Although, there is a Cisco networking technology called CEF that I thought you were talking about, at first, which only makes things more confusing.)
Hmm, I guess I would have been even more mad if VMWare client had altered the routing table.
I don't understand your problem with loopback. That method of IPC has been around, like, for 40 years at least? It's hardly unusual to talk to yourself over loopback. What's "moronic" is requiring a private alias to tell you what is the loopback addr.
IPC is mentally-:censored: thinking that needs to die off. Steam's modern UI is literally a self-contained web-browser and server at the same time. That's :censored: STUPID. CEF, Chromium Embedded Framework. Developers all around the world have gotten :censored: LAZY and use such ugly UIs using :censored: like CEF that destroy accessibility by...doing accessibility. Buttons have become so :censored: massive and text is so large I can't read as fast as I could. Lowering font-size to increase the amount of text on screen doesn't help when the UI elements are so :censored: large as if every single person on the planet has suddenly become blind or can't find dark-pattern-enforced buttons. Nightmarish.
Besides, I brought up the loopback space only because you brought it up. The
hostsrules could have been respected if VMWare had just chosen a unique addr; then they could have added the line--TO THE END OF THE FILE, NOT THE BEGINNING!--and everything would have worked out. And wouldn't that have been better for routing, too? It's a whole Class A go work with! Why not make you own "localhost subnet"? I still don't see what this has to do with mdns or resolution. I mean, IP routing happens at the IP layer; there are no names in routing. But, as I say, CEF is new to me. (Although, there is a Cisco networking technology called CEF that I thought you were talking about, at first, which only makes things more confusing.)
It's the way the hostname is being looked up. It's a :censored: up round-about way to get around CEF/routing issues. The hostname needs to be something besides "localhost" or they'd interact with other services. Using the loopback host they get Steam client and can prevent external routing and other software issues. The whole mdns issue is actually part of the problem. I can't recall what backend is bugging out but it is. The bug technically isn't in Steam, I'm :censored: because Steam shouldn't be using CEF to begin with.
Edit: As for the position in the file...nah, adding a static entry at the beginning prevents lookup using external services, VMware's got that part right. No failure, no delay, it's just wonk how they did it. Half-right, half-wrong. Steam just blows their foot off entirely by using CEF.
Interesting. I'm certainly on your side about having a web-server and client as your "app". No arguments there; that is pretty stupid. On the other hand, it's nice to have a hard separation between UI and functionality. I wouldn't want a whole HTTP server + client between the two, but if you have the separation, you can put anything in between you like, I guess. But, yeah, CEF sounds lame. I'm guessing that it has something to do with the whole thing where everything has to be "mobile", and we need to trash all the desktop apps until they suck. This is why we can't have nice things. Cheers, mate.
Hey, thanks everyone for all the info.
First, a small clarification. The steamloopback.host hostname is unrelated to the websocket connection error. It gets printed as a prefix to each message in the log file because that is where the js file was loaded from. But it shouldn't be involved at all in the websocket connection.
The websocket connection is initiated by the steamwebhelper process, and it tries to connect to localhost. From what I've read in the reports above, it seems like there is a problem in resolving localhost in some systems. We can probably make this more reliably on the steam side by trying 127.0.0.1 if connecting to localhost fails.
I would like to confirm that this is the case though. For anyone experiencing the issue, could you collect the following info:
ping -4 -c 1 localhostping -6 -c 1 localhostpstree when steam is runningtar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs. In particular, the relevant files are webhelper.txt and transport_steamui.txt if you'd prefer to share just those two.For users where this issue can be triggered by changing your hosts file, it would be good to know if the above ping commands yield any different results with the good/bad hosts configurations.
For users where this issue can be triggered by changing your hosts file, it would be good to know if the above
pingcommands yield any different results with the good/bad hosts configurations.
Testet den above ping commands with 127.0.0.1 localhost added to top of hosts-file and as the second entry.
With localhost being the top entry in hosts:
~$ ping -4 -c 1 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.019 ms
--- localhost ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.019/0.019/0.019/0.000 ms
With localhost being the second entry from top:
~$ ping -4 -c 1 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from view-localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.030 ms
--- localhost ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.030/0.030/0.030/0.000 ms
As you can see there an increased delay. Also note that response is coming from view-localhost, which is an entry I believe was added by the VMware Horizon Client.
The other command ping -6 -c 1 localhost produce the same result for both settings:
~$ ping -6 -c 1 localhost
ping: localhost: Address family for hostname not supported
This is because I don't use IPv6.
Attaching pstree output and steam logs for when I have localhost set as second entry from the top.
pstree.txt
steam-logs.tar.gz
No, you can use your own DNS server to set up steamloopback.host to whatever you want and your machine can resolve it, yes even via Steam (Steam client modifiers salute, queries for the address DO leave the client), so that's bull. My local network's DNS server logs the queries for it as well. Technitium and Pi-Hole users can check too.
Edit: After all, if it was local (to code only) then a steamloopback.host DNS entry would never need to exist in the first place.
Edit: So all the kiddies at home can nslookup steamloopback.host instead of attempting to ping localhost (or even steamloopback.host) to distract from the design of things. No one said that steamloopback.host is a remote host, that's not what is being fussed about. It's about using a web browser as a UI client even if locally hosted.
@OdinVex My understanding is that this issue is about the client taking a long time start due to the websocket connection between steamwebhelper and steam fails to be established.
If you have concerns about steamloopback.host, can I trouble you to put them in a separate issue?
You misunderstand this entire thread. The problem is being caused by the steamloopback.host lookup. The bug is external, it isn't Steam that is at fault, but the GRIPE is that Steam shouldn't be using a damn web browser and embedded server (Chromium Embedded Framework) to masquerade as a desktop software to begin with (which has a reliance on this lookup). Adjusting hosts circumvents the lookup bug of avahi (or whatever, I forgot, been a while) which hides the bug, switching from mdns to mdns_minimal hides the bug as well, but the issue is in the actual lookup software on most Linux distros. It still doesn't get rid of the fact Steam is using a crummy framework. Web browsers are not desktop software.
@royborgen thanks again for the info. I can reproduce the problem locally based on the data you provided.
So this is what Linus feels like dealing with others, ugh.
And no, you've reproduced nothing related to the bug here. We're talking 5 minutes to 1 HOUR long start times (because of Avahi configurations varying about mdns handling, some can be an hour or even indefinite), not milliseconds, has nothing to do with IPv4/IPv6 entries for the bug here, that's a separate but real issue.
Thanks everyone, a fix is queued up. I will update this issue once it makes it to a public build.
facepalm You're talking about two different issues and two different causes. This is exactly why I hate closed-source software.
You're talking about two different issues and two different causes.
I don't disagree with you there. This is why above I suggested opening a separate issue.
@royborgen the fix should be available in the latest beta. Can you confirm it also works on your side?
@royborgen the fix should be available in the latest beta. Can you confirm it also works on your side?
That seems to have fixed it :)
Thanks a lot <3
Thanks for checking. Closing this issue for now as the other user reports with logs had the same symptoms in them.
Your system information
Please describe your issue in as much detail as possible:
Recently when starting Steam, the tray icon appears immediately, but using any of the menu items does not work, and the Steam client does not appear.
Sometimes the client does appear after waiting for several minutes. I am not sure If this is always the case and I just was not patient enough most of the time.
When launching from the console it outputs this after hanging:
This seems to me like something tries to connect to a websocket and the interface only continues initializing after the connection timeouts.
After appearing the interface does seem to work normally, so I am not sure what kind of websocket connection is failing.
This might be connected to #9658, but the problem started very recently for me and the mentioned issue seems to be a lot older.
Steps for reproducing this issue: