search

ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.19k stars 174 forks source link

Steam takes very long to start, failed to connect to websocket #10879

Open peacememories opened 3 months ago

peacememories commented 3 months ago

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:

src/steamUI/webuitransportcontroller.cpp (206) : Failed to connect to websocket

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:

  1. Start steam
  2. The interface does not appear
  3. Try to click on the tray icon and select "Library
  4. The interface still does not appear
  5. Wait for several minutes
  6. The interface appears
kisak-valve commented 3 months ago

Hello @peacememories, can you check if this is the same issue as discussed on #9383?

usersteamdebian commented 3 months ago

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

YoinkerBoinker commented 3 months ago

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

UrsusLvovich commented 3 months ago

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

OdinVex commented 3 months ago

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

wwmm commented 3 months ago

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.

wwmm commented 3 months ago

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...

fmorgner commented 3 months ago

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
OdinVex commented 3 months ago

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.

peacememories commented 3 months ago

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)

RisaI commented 3 months ago

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

OdinVex commented 3 months ago

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.

OdinVex commented 2 months ago

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.

RisaI commented 2 months ago

@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.

oliverlynch commented 2 months ago

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.

RisaI commented 2 months ago

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.

OdinVex commented 2 months ago

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.

RisaI commented 2 months ago

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)
OdinVex commented 2 months ago

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.

cpmiller commented 2 months ago

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.

OdinVex commented 2 months ago

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.)

gtdm commented 2 months ago

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.

OdinVex commented 2 months ago

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.)

fmorgner commented 2 months ago

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.

OdinVex commented 2 months ago

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.

Interesting. I disabled systemd-resolved and switched to minimal, working.

DiegoGiovany commented 2 months ago

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
OdinVex commented 2 months ago

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?

fmorgner commented 1 month ago

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)

OdinVex commented 1 month ago

...

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.

mattaw commented 1 month ago

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.

another-username2 commented 1 month ago

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 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

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?

OdinVex commented 1 month ago

@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

Not-Zero-Blank commented 1 month ago

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

OdinVex commented 1 month ago

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.

akrychowski commented 1 month ago

On fedora 40 affected by this problem, removing the 127.0.0.1 view-localhost in hosts helped.

royborgen commented 1 month ago

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

royborgen commented 1 month ago

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

colinmarc commented 3 weeks ago

Confirmed this bug on a Manjaro machine with multiple hyphens in the hostname. I'm flabbergasted that this is a real thing.

OdinVex commented 3 weeks ago

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).

OdinVex commented 3 weeks ago

@kisak-valve Bumping for possible tag update such as "confirmed" or whatever to get some eyes on it?

Acithium commented 1 week ago

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.

PorcelainMouse commented 5 days ago

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.

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.

OdinVex commented 5 days ago

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.

DollarStoreCPU commented 4 days ago

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.