Skip to content

Exit status of the launched command is not propagated: gamescope always exits 0 #2540

Open

Description

@BiNeurale

Current Behavior:

gamescope exits with status 0 whatever the command after -- returns, including when it is
killed by a signal. I use gamescope's headless backend to run automated render checks, and a
failing check looks like a pass to the calling script.

Looking at the source (309eee7), the status seems to be dropped in two places:
gamescopereaper waits for its child with WaitForAllChildren(nPrimaryChild) and then
returns 0 (src/Apps/gamescopereaper.cpp), and the gamescope-wait thread in
steamcompmgr.cpp ignores the status returned by WaitForChild() for the reaper; main()
then falls off the end. Since this is not backend-specific I expect the other backends to
behave the same, but I only tested headless.

Expected: gamescope exits with the primary child's exit status (and 128+N if it was killed
by signal N), like env, timeout or xvfb-run do. If changing the default is a concern, an
option to enable it would also work for me.

Steps To Reproduce:

gamescope --backend headless -- sh -c 'exit 7'; echo $?          # prints 0, expected 7
gamescope --backend headless -- false; echo $?                   # prints 0, expected 1
gamescope --backend headless -- sh -c 'kill -SEGV $$'; echo $?   # prints 0, expected 139

Hardware information:

  • Distro: CachyOS (kernel 7.3.1-1-cachyos)
  • CPU: AMD Ryzen APU (Renoir)
  • GPU: AMD Radeon Graphics (RADV RENOIR)
  • Driver Version: Mesa 26.2.6

Software information:

  • Desktop environment: KDE Plasma (not involved, headless backend)
  • Session type: wayland
  • Gamescope version: gamescope version 3.17.0 (gcc 16.2.1), package 3.17.0-1
  • Gamescope launch command(s): gamescope --backend headless -- <cmd>

Backends: headless (not in the checkbox list); others not tested.

Checks

  • I searched existing issues
  • Reproduced with an unmodified gamescope build (distribution package)

Activity

  1. JROtto5 commented on Nov 6, 2026

    @JROtto5

    I have a fix for this. gamescopereaper and the gamescope-wait thread now pass the primary child's status through, with 128 + N for a child killed by signal N and 127 for a command that can't be started. There are tests that run gamescopereaper itself. Nested on KDE Wayland, exit 7, false and a SIGKILL give 7, 1 and 137, and shutting gamescope down itself still exits 0. I'll open a PR shortly.

  2. BiNeurale commented on Nov 6, 2026

    @BiNeurale
    Author

    Thanks! I had a fix ready as well and opened it as #2541 (reaper + gamescope-wait, 128 + N for signals, 127 for exec failure, tests that run gamescopereaper). Happy to compare notes, or to test yours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions