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

Đang mở
#1,052 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
linux, shell
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
Shell
Star
1.1k
Fork
56
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ValveSoftware/SteamVR-for-Linux

Tất cả issue của ValveSoftware/SteamVR-for-Linux

Issue tương tự

Thêm issue về Shell/Bash

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.