[BUG] vrmonitor gives up on vrcompositor after ~5s while a cold first compositor start takes ~10s

オープン
  • 何か問題がありますか？
#1,052 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
linux, shell
領域
backend

調査の方向性

Start by tracing the vrmonitor-to-vrserver compositor startup path around VRMsg_StartVRCompositor and the five-second timeout described in the issue; the payload does not name source files or tests. Compare the timeout behavior with the logged 10.2-second cold start through vrcompositor-launcher.sh and identify where startup is treated as a hard failure. Done means cold starts can complete without vrmonitor giving up and leaving the session in the legacy scene; the issue does not specify a test or the desired timeout or response design.

索引モデルが issue の本文から書いたものです。

説明

Describe the bug

Cold-starting SteamVR 2.19.2 on Linux, vrmonitor asks vrserver to start vrcompositor and gives up after ~5 seconds (Failed to start vrcompositor. Giving up), but on this machine that first compositor start takes 10.2 s, because vrcompositor-launcher.sh re-execs the compositor into the Legacy runtime to gain CAP_SYS_NICE. The compositor does come up 5 s later and works fine - but the session is already broken: vrmonitor logs SteamVR Fail (-201) once a second and the headset shows the legacy grid environment instead of the normal one.

To Reproduce

  1. Make sure SteamVR is not running at all (so the compositor has to do its first-start Legacy-runtime escape).
  2. Start SteamVR from Steam with a Quest 3 connected over Steam Link (the built-in vrlink driver).
  3. Watch vrmonitor time out on the compositor while vrserver is still inside the blocking VRMsg_StartVRCompositor call.

Expected behavior

The compositor wait should either be long enough for a cold first start, or the client should get a "still starting" answer instead of a hard failure - and after the failure the session should not silently half-load the legacy scene, which makes it look like a corrupt install rather than a startup timeout.

Versions

  • SteamVR 2.19.2 (v1794004177), launched as tool AppID 250820 from Steam client buildid 1792618285 (Sniper runtime)
  • Distro/kernel: CachyOS, 7.3.1-1-cachyos, Wayland/GNOME
  • GPU: NVIDIA RTX 5080, driver 615.78.08
  • HMD: Meta Quest 3, wireless, via vrlink

Log dump

Timeline plus the relevant excerpts from vrserver.txt, vrclient_vrmonitor.txt, vrmonitor.txt, vrcompositor.txt, vrstartup-linux.txt and driver_vrlink.txt: https://gist.github.com/ackalker/a93aa0930da3e43b2bb6a2c6a5b99367

The short version:

vrclient_vrmonitor.txt  14:00:17.769 CIPCPipe::ConnectPipe(VR_CompositorPipe_277692) ... Unable to connect to pipe errno=111
vrclient_vrmonitor.txt  14:00:22.774 Timeout while waiting for message of type 136 on pipe VR_ServerPipe_277692
vrclient_vrmonitor.txt  14:00:22.774 Failed to start vrcompositor. Giving up
vrserver.txt            14:00:28 VRMsg_StartVRCompositor from 277716: vrmonitor took 10.2132 seconds   (also from vrwebhelper_main, vrwebhelper_pairing, vrwebhelper_settings_desktop, steam, vrdashboard)
vrcompositor.txt        14:00:28.081 vrcompositor 2.19.2 startup with PID=278110
vrstartup-linux.txt     14:00:27.852 vrcompositor-launcher.sh[278110]: Relaunching under Legacy runtime (to allow us to gain the CAP_SYS_NICE bit)
vrmonitor.txt           14:00:28.085 [Status Alert] SteamVR Fail (-201)   (88 of these, one per second)

Additional context

  • VRAM pressure is not the reason for the 10 s. Right after the compositor came up, VRMsg_CreateSwapTextureSet took 0.006-0.019 s, while an unrelated process held ~14.7 of 16 GiB. The time goes into the Pressure Vessel bootstrap (steam-runtime-launch-client --alongside-steam, scout/Legacy runtime detection).
  • At shutdown this session also produced 51 SharedResourceManager: detected possible leak lines in vrcompositor.txt and 36 Error: Failed to unref VRCompositor resource lines in vrserver.txt - looks related to #990.
  • Knock-on effect outside SteamVR: one process of the SteamVR launch chain (the vrserver supervisor, PID 277953) survived its own server child (which had logged [vrserver] Graceful exit), sat in futex_wait for ~20 minutes ignoring SIGTERM, and kept the Steam-side launch chain alive, so Steam could not finish quitting. Filed separately against the Steam client: https://github.com/ValveSoftware/steam-for-linux/issues/13853
主要言語
Shell
スター
1.1k
フォーク
56
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ValveSoftware/SteamVR-for-Linux のほかの issue

ValveSoftware/SteamVR-for-Linux の issue をすべて見る

似ている issue

Shell/Bash の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。