[Linux][COSMIC] Portal capture blocks startup indefinitely waiting for consent — no ports bind, no timeout (headless host)

Open
  • Is something wrong?
#6,080 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp, linux
Domain
backend, operating-systems

Research direction

Start by tracing the Linux portal capture startup path around the logged RemoteDesktop CreateSession and SelectSources calls in portalgrab; reproduce on COSMIC with portal capture and compare with the working capture = kms path. The issue names no source files or tests, so locate the startup and listener initialization entry points first. Done means portal setup cannot leave startup blocked indefinitely and reports a useful failure or proceeds through an available fallback.

Written by the indexing model from the issue text.

Description

Is there an existing issue for this?
  • I have searched the existing issues (closest: #5750 — portal hang on client connect on GNOME headless; this one hangs at startup before any port binds, on COSMIC)
Is your issue described in the documentation?
  • I have read the documentation
Is your issue present in the latest beta/pre-release?

Not tested yet — reproduced on latest stable v2026.914.233613 (commit 63d35f7).

Describe the Bug

With the default capture method on a COSMIC Wayland session, Sunshine blocks indefinitely during startup inside the portal (portalgrab) RemoteDesktop/ScreenCast handshake. After SelectSources returns, it never logs anything else, never binds any ports (47984/47989/47990/48010), and never times out or errors. systemd reports the unit as active (running), so from the outside it looks healthy, but Moonlight can't find the host and the web UI is unreachable.

It appears to be waiting for the portal consent/source-picker step to be answered on the physical display. On a headless box (HDMI dummy plug, nobody at the console) that never happens, so Sunshine stayed in this state for 4+ days until it was noticed. It reproduces on every restart and on a fresh boot.

Debug log of the hang (nothing follows the last line until killed):

[14:58:22.371]: Error: Failed to create session:
...
[14:58:22.373]: Info: --------- End of KMS monitor list ---------
[14:58:22.373]: Debug: Final KMS display_names return list: HDMI-A-1
[14:58:22.377]: Debug: [portalgrab] RemoteDesktop CreateSession response_code: 0
[14:58:22.377]: Debug: [portalgrab] RemoteDesktop CreateSession: got session handle: /org/freedesktop/portal/desktop/session/1_169/Sunshine1
[14:58:22.378]: Debug: [portalgrab] SelectDevices response_code: 0
[14:58:22.378]: Debug: [portalgrab] SelectSources response_code: 0
[14:58:52.236]: Info: Terminate handler called          <- killed by `timeout 30`
[14:59:02.237]: Fatal: 10 seconds passed, yet Sunshine's still running: Forcing shutdown

xdg-desktop-portal-cosmic logged Failed to send remote desktop event: channel closed when Sunshine was killed.

While hung, every thread is sleeping (main thread in poll, others in futex), CPU time ~0.

Setting capture = kms works around it: Sunshine starts immediately, finds NVENC, binds all ports, and streams fine.

Expected Behavior
  • Portal session setup shouldn't block startup (and the nvhttp/confighttp listeners) indefinitely. A timeout with a clear error such as "portal did not respond / consent not granted — is anyone at the display? consider capture=kms" would make this diagnosable.
  • Ideally, if the portal step doesn't complete, fall back to another available capture method (KMS works here, and the binary already has cap_sys_admin).
Additional Context
  • Headless host: HDMI dummy plug (EDID "Evanlak8K V2", 3840x2160), no monitor or keyboard attached.
  • Related observation, possibly separate: Sunshine segfaults repeatedly on stop (see #5586). Once, the systemd Restart= that followed came up with Error: Unable to initialize capture method / Platform failed to initialize, then Failed to gain CAP_SYS_ADMIN for every encoder, and Moonlight got "503 failed to initialize video capture". A clean systemctl --user restart fixed it. Same symptom as #5803, but intermittent here.
Host Operating System

Linux

Operating System Version

Pop!_OS 24.04 LTS, kernel 7.2.15, COSMIC (cosmic-comp 0.11793802426, xdg-desktop-portal 1.18.4, xdg-desktop-portal-cosmic 1.11.01792525517)

Architecture

amd64/x86_64

Package

Linux - deb (sunshine 2026.914.233613-1+ubuntu24.04), run as the packaged user unit app-dev.lizardbyte.app.Sunshine.service

GPU Type

NVIDIA

GPU Model

GeForce RTX 3080

GPU Driver/Mesa Version

NVIDIA 595.104.02 (open kernel module)

Capture Method

Portal (default) → hangs; KMS → works

Dominant language
C++
Stars
43k
Forks
2.4k
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LizardByte/Sunshine

All issues in LizardByte/Sunshine

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.