Open peacememories opened 3 months ago
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 16C32T@4.5GHz 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
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.
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/hosts
with: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
mdns
tomdns_minimal
seems 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 16C32T@4.5GHz 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
files
up 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/hosts
with: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.
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/hosts
and 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/hosts
and 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.
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: