After updating to client build 1791918634 (2026-10-16), Steam fails to bring up its UI on a machine where ~/.steam lives on NFS: the client gives up waiting for webhelper init (Timed out waiting for webhelper init), and no UI is ever created — permanent blank/black screen, no dialog, no retry. The webhelper's startup is dominated by pressure-vessel assembling the runtime under ~/.steam/steamrt64/pv-runtime/steam-runtime-steamrt/, which on this filesystem now takes hundreds of seconds — far beyond the client's wait window.
Numbers (same machine, same NFS home)
Build 1788652215 (2026-10-08 → 10-11): Starting steamwebhelper ... via _v2-entry-point → exec ./steamwebhelper routinely took 49–64 s; Steam worked. (One isolated Timed out waiting for webhelper init line exists in older logs too, but it was not systematic.)
Build 1791918634 (2026-10-16): the same span took 362 s on the first boot after the update; direct timing of the same entry point (_v2-entry-point --verb=run -- /bin/true) on subsequent runs while the system was idle: 226 s and 322 s. No UI ever appeared.
After relocating pv-runtime to local storage (workaround below): the same span is 1 s, UI up ~46 s after start (STARTUP SteamUI browser requested at +1569ms, vs +122327ms on the failed runs).
$HOME (and ~/.steam) is an NFSv4.2 mount (hard,timeo=600); server metadata latency ~15–25 ms/op (measured — the filesystem itself is healthy)
Logs
logs/steamui_html.txt (failed boot):
[2026-10-16 16:00:21] Started webhelper process 6911
[2026-10-16 16:00:21] Timed out waiting for webhelper init
[2026-10-16 16:00:21] STARTUP SteamUI browser requested at +122327ms
logs/webhelper-linux.txt (same boot — the time is spent inside the runtime entry point, before exec):
Mechanism measured: while _v2-entry-point runs, pressure-vessel-wrap sits in D state (wchan=rpc_wait_bit_killable) repeatedly calling linkat() to assemble the runtime (steamrt3c_platform_3c.0.20260824.257593) into steam-runtime-steamrt/var/tmp-*/... — a 17,673-file tree, one synchronous NFS metadata op per file. The var/tmp-* staging is redone on every launch in this environment (we could not observe reuse of a completed assembly), so every launch pays the full cost — and with build 1791918634 that cost exceeds the client's wait window every time.
Mitigation that fixed it: move ~/.steam/steamrt64/pv-runtime onto local storage and bind-mount it back into place. Steam updates/writes go through the mount; no Steam data was touched. This is a workaround — the client behavior (hard timeout + no retry + no user-visible error) is what turns a slow filesystem into a permanently blank Steam.
Requests
Make the webhelper-init wait adaptive/retryable, or surface a visible error with a retry option, instead of permanently giving up.
Check why the pressure-vessel runtime staging under pv-runtime/steam-runtime-steamrt/ is repeated (not reused) on network filesystems, and whether that assembly can be made resilient to high per-op latency.
Related: #10431 tracks the long-standing NFS sensitivity of the client (previous failure mode: "Steamwebhelper is not responding" crash dialog). This report is a distinct regression: with the current build the failure is silent — no dialog, no UI, no retry.
Full ~/.steam/steam/logs from both the failing and the fixed boots available on request.
Summary
After updating to client build
1791918634(2026-10-16), Steam fails to bring up its UI on a machine where~/.steamlives on NFS: the client gives up waiting for webhelper init (Timed out waiting for webhelper init), and no UI is ever created — permanent blank/black screen, no dialog, no retry. The webhelper's startup is dominated by pressure-vessel assembling the runtime under~/.steam/steamrt64/pv-runtime/steam-runtime-steamrt/, which on this filesystem now takes hundreds of seconds — far beyond the client's wait window.Numbers (same machine, same NFS home)
1788652215(2026-10-08 → 10-11):Starting steamwebhelper ... via _v2-entry-point→exec ./steamwebhelperroutinely took 49–64 s; Steam worked. (One isolatedTimed out waiting for webhelper initline exists in older logs too, but it was not systematic.)1791918634(2026-10-16): the same span took 362 s on the first boot after the update; direct timing of the same entry point (_v2-entry-point --verb=run -- /bin/true) on subsequent runs while the system was idle: 226 s and 322 s. No UI ever appeared.pv-runtimeto local storage (workaround below): the same span is 1 s, UI up ~46 s after start (STARTUP SteamUI browser requested at +1569ms, vs+122327mson the failed runs).System information
$HOME(and~/.steam) is an NFSv4.2 mount (hard,timeo=600); server metadata latency ~15–25 ms/op (measured — the filesystem itself is healthy)Logs
logs/steamui_html.txt(failed boot):logs/webhelper-linux.txt(same boot — the time is spent inside the runtime entry point, beforeexec):console-linux.txtthen shows (twice), and nothing else — the UI is never created:Mechanism measured: while
_v2-entry-pointruns,pressure-vessel-wrapsits inDstate (wchan=rpc_wait_bit_killable) repeatedly callinglinkat()to assemble the runtime (steamrt3c_platform_3c.0.20260824.257593) intosteam-runtime-steamrt/var/tmp-*/...— a 17,673-file tree, one synchronous NFS metadata op per file. Thevar/tmp-*staging is redone on every launch in this environment (we could not observe reuse of a completed assembly), so every launch pays the full cost — and with build 1791918634 that cost exceeds the client's wait window every time.Mitigation that fixed it: move
~/.steam/steamrt64/pv-runtimeonto local storage and bind-mount it back into place. Steam updates/writes go through the mount; no Steam data was touched. This is a workaround — the client behavior (hard timeout + no retry + no user-visible error) is what turns a slow filesystem into a permanently blank Steam.Requests
pv-runtime/steam-runtime-steamrt/is repeated (not reused) on network filesystems, and whether that assembly can be made resilient to high per-op latency.Related: #10431 tracks the long-standing NFS sensitivity of the client (previous failure mode: "Steamwebhelper is not responding" crash dialog). This report is a distinct regression: with the current build the failure is silent — no dialog, no UI, no retry.
Full
~/.steam/steam/logsfrom both the failing and the fixed boots available on request.