[Bug]: Sunshine virtual input devices are exposed in sysfs but missing in /dev/input, causing Moonlight keyboard/mouse input failure and Xorg restart/crash loops

[pin00b]

Describe the Bug

After a recent NVIDIA driver / container restart scenario, the container starts far enough that WebVNC and Moonlight video streaming can work, but Moonlight keyboard and mouse input are unavailable.

The root cause appears to be that Sunshine creates virtual input devices visible under /sys/class/input/event*/device/name, for example:
Mouse passthrough Mouse passthrough (absolute) Keyboard passthrough

but the matching character device nodes are not reliably present under /dev/input/ inside the container.

When Xorg tries to attach these Sunshine virtual input devices via udev, it sees the sysfs entries and attempts to use /dev/input/event5, /dev/input/event6, and /dev/input/event7, but those nodes may not exist. This causes errors such as:
evdev: Keyboard passthrough: Unable to open evdev device "/dev/input/event7" (No such file or directory). PreInit returned 2 for "Keyboard passthrough" evdev: Mouse passthrough: Unable to open evdev device "/dev/input/event5" (No such file or directory).

In some startup orders, this also leads to repeated Xorg restarts / crash loops and repeated:
Fatal server error: Server is already active for display 55

A manual workaround is to recreate the missing /dev/input/event* nodes from the major/minor numbers in /sys/class/input/event*/dev, install/use the evdev Xorg input config, and restart Xorg after the nodes exist. After that, Moonlight keyboard and mouse input works.

Steps to Reproduce

1. Run the steam-headless container with Sunshine enabled and NVIDIA GPU acceleration.
2. Start or restart the container after the recent NVIDIA driver / environment change.
3. Connect via WebVNC.
4. Connect via Moonlight.
5. Observe that video output works, but keyboard/mouse input from Moonlight does not work.
6. Inside the container, check Sunshine virtual input devices:

for e in /sys/class/input/event*; do
  [ -e "$e/device/name" ] || continue
  name="$(cat "$e/device/name" 2>/dev/null)"
  dev="$(cat "$e/dev" 2>/dev/null)"
  echo "$(basename "$e") dev=$dev name=$name"
done

Example output:

event5 dev=13:69 name=Mouse passthrough
event6 dev=13:70 name=Mouse passthrough (absolute)
event7 dev=13:71 name=Keyboard passthrough

7. Compare with /dev/input:
   ls -la /dev/input

8. Check Xorg logs:

grep -nEi "Keyboard passthrough|Mouse passthrough|Unable to open|Failed to create|No such device|Server is already active|Fatal server error" \
  /var/log/Xorg.55.log /home/default/.cache/log/xorg.err.log 2>/dev/null | tail -120

Expected Behavior

Sunshine’s virtual keyboard/mouse/touch input devices should be usable by Xorg inside the container without manual intervention.

When Sunshine creates virtual input devices, the corresponding /dev/input/event* character nodes should exist, have usable permissions, and Xorg should attach them successfully.

Moonlight keyboard and mouse input should work after container start/restart.

Xorg should not enter a restart/crash loop because of stale/missing Sunshine input device nodes.

Screenshots

na

Relevant Settings

steam-headless container
Sunshine enabled
Xorg display: :55
WebVNC enabled
Moonlight client used for streaming/input
NVIDIA GPU acceleration

Relevant effective workaround:

mkdir -p /etc/X11/xorg.conf.d
cp -f /usr/share/X11/xorg.conf.d/10-evdev.conf /etc/X11/xorg.conf.d/10-evdev.conf

Ensure Xorg input auto-add is not disabled:
sed -i "/AutoAddDevices/d;/AutoEnableDevices/d" /etc/X11/xorg.conf

Create missing device nodes from sysfs:

mkdir -p /dev/input

for e in /sys/class/input/event*; do
  [ -e "$e/device/name" ] || continue
  name="$(cat "$e/device/name" 2>/dev/null || true)"

  case "$name" in
    *passthrough*|*Sunshine*)
      ev="$(basename "$e")"
      dev="$(cat "$e/dev")"
      maj="${dev%:*}"
      min="${dev#*:}"
      path="/dev/input/$ev"

      rm -f "$path"
      mknod "$path" c "$maj" "$min"
      chown root:input "$path" 2>/dev/null || chown root:root "$path"
      chmod 660 "$path"
      ;;
  esac
done

Then restart Xorg/desktop/x11vnc after the nodes exist while keeping Sunshine available. After this, logs show successful attachment:

Using input driver 'evdev' for 'Mouse passthrough'
XINPUT: Adding extended input device "Mouse passthrough"
Using input driver 'evdev' for 'Keyboard passthrough'
XINPUT: Adding extended input device "Keyboard passthrough"

Version

josh5/steam-headless:latest; Sunshine version: 2025.924.154138 commit: 86188d47a7463b0f73b35de18a628353adeaa20e Package Publisher: LizardByte

Platform

Distribution: <output of: . /etc/os-release; echo "${NAME} - ${VERSION}">
Linux Kernel: <output of: uname -rpio>
GPU Driver versions: <output of: nvidia-smi | grep 'Version:'>
Docker: <output of: docker -v>
Docker-compose: <output of: docker compose -v>

Host: Unraid-based system
Container: steam-headless
GPU: NVIDIA
Streaming client: Moonlight
WebVNC: works
Moonlight video: works
Moonlight keyboard/mouse input: broken until /dev/input nodes are recreated and Xorg reattaches them via evdev

Relevant log output

/sys/class/input/event5/device/name -> Mouse passthrough
/sys/class/input/event6/device/name -> Mouse passthrough (absolute)
/sys/class/input/event7/device/name -> Keyboard passthrough

Broken state:
(II) config/udev: Adding input device Keyboard passthrough (/dev/input/event7)
(**) Keyboard passthrough: Applying InputClass "evdev keyboard catchall"
(II) Using input driver 'evdev' for 'Keyboard passthrough'
(**) evdev: Keyboard passthrough: Device: "/dev/input/event7"
(EE) evdev: Keyboard passthrough: Unable to open evdev device "/dev/input/event7" (No such file or directory).
(EE) PreInit returned 2 for "Keyboard passthrough"

(II) config/udev: Adding input device Mouse passthrough (/dev/input/event5)
(**) Mouse passthrough: Applying InputClass "evdev pointer catchall"
(II) Using input driver 'evdev' for 'Mouse passthrough'
(**) evdev: Mouse passthrough: Device: "/dev/input/event5"
(EE) evdev: Mouse passthrough: Unable to open evdev device "/dev/input/event5" (No such file or directory).
(EE) PreInit returned 2 for "Mouse passthrough"

Working state after manually recreating /dev/input/event5, /dev/input/event6, and /dev/input/event7:
(II) config/udev: Adding input device Mouse passthrough (/dev/input/event5)
(**) Mouse passthrough: Applying InputClass "evdev pointer catchall"
(II) Using input driver 'evdev' for 'Mouse passthrough'
(**) evdev: Mouse passthrough: Device: "/dev/input/event5"
(--) evdev: Mouse passthrough: Vendor 0xbeef Product 0xdead
(--) evdev: Mouse passthrough: Found 12 mouse buttons
(--) evdev: Mouse passthrough: Found relative axes
(II) evdev: Mouse passthrough: Configuring as mouse
(II) XINPUT: Adding extended input device "Mouse passthrough" (type: MOUSE)

(II) config/udev: Adding input device Keyboard passthrough (/dev/input/event7)
(**) Keyboard passthrough: Applying InputClass "evdev keyboard catchall"
(II) Using input driver 'evdev' for 'Keyboard passthrough'
(**) evdev: Keyboard passthrough: Device: "/dev/input/event7"
(--) evdev: Keyboard passthrough: Vendor 0xbeef Product 0xdead
(--) evdev: Keyboard passthrough: Found keys
(II) evdev: Keyboard passthrough: Configuring as keyboard
(II) XINPUT: Adding extended input device "Keyboard passthrough" (type: KEYBOARD)

[atassis]

Reproduced on TrueNAS SCALE 25.04 (kernel 6.12, ix-app deployment) with josh5/steam-headless:latest rebuilt 2026-05-02, NVIDIA driver 595.58.03, dual RTX 4060 Ti + 5060 Ti, /dev/input and /dev/uinput passed through, MODE=primary, ENABLE_SUNSHINE=true.

Symptom: every 6–7 seconds, Xorg is restarted, which cascades to desktop (startxfce4 sees the still-up X server and exits 1), x11vnc (exits 3), and sunshine (gets SIGINT, exit 130). Sunshine successfully completes encoder probe, enters main loop, and even serves Moonlight GET /serverinfo requests for ~3 seconds before being killed. From the user-facing side: pairing/streaming is unusable.

Mechanism — the xorg-restarted flag in start-dumb-udev.sh introduced in 096fc4b is self-clearing:

while true; do
    sync_input_nodes
    if sunshine_inputs_present; then
        if [[ ! -e "${state_dir}/xorg-restarted" ]]; then
            ...
            supervisorctl restart xorg >/dev/null 2>&1 || true
            : > "${state_dir}/xorg-restarted"
        fi
    else
        rm -f "${state_dir}/xorg-restarted"   # <-- fires every cycle
    fi
    sleep 1
done

Sunshine's libevdev gamepads/keyboard/mouse exist from daemon startup (not just on Moonlight client connect — the comment above the block has this premise wrong). So:

1. Sunshine starts → sunshine_inputs_present=true, no flag → restart xorg, set flag.
2. Cascade kills sunshine → its libevdev devices disappear from sysfs → sunshine_inputs_present=false → flag is cleared in the else branch.
3. Sunshine respawns → goto 1. Infinite loop.

Why this setup is invisible to the patch: with /dev/uinput passed through, libevdev mknods the /dev/input/event* nodes itself when it creates the virtual devices, so sync_input_nodes is a no-op for me. The whole sync-then-restart-Xorg workaround isn't needed on this host — it's pure damage.

Workaround (until a proper fix lands): override the one line in start-dumb-udev.sh. The udevd daemon launch and sync_input_nodes loop still run, only the trigger is gated:

sed -i 's|supervisorctl restart xorg|true # disabled|' /usr/bin/start-dumb-udev.sh
supervisorctl restart udev

After this, all four services hold stable RUNNING, sunshine's UI at :47990 is reachable, and Moonlight pairing works.

Possible upstream fixes (not submitting a PR — moving to a Wayland-native solution for my use case):

• Never clear the xorg-restarted flag (one-shot per container lifetime).
• Or: only clear after the absence has lasted, say, ≥30s, to filter out the cascade's brief gap.
• Or: trigger off real udev add events (track seen device names in a set, fire only on new ones).
• Or: skip the whole block when /dev/uinput is passed through and libevdev is creating nodes natively.

Hope this helps narrow it down for #224 and #230 as well — both look like the same root cause.

[atriusreal]

@atassis Any chance I could get your Truenas .yaml file?

Right now my fix is completely shutting off Sunshine, and just play with Steam Remote Play which works decently well actually.

Is your fix applicable for users too? Can i fix it on my end? Thanks!

[pin00b]

@atassis Thanks for your comment and the confirmation of the bug itself. I have an indirect confirmation of your workaround, since I got a manual created steam-headless container working as it should, which obviously works, because the problematic restart routing doesn't seem to exist in this container!

docker exec steam-headless bash -lc '
echo "=== does start-dumb-udev.sh exist? ==="
ls -l /usr/bin/start-dumb-udev.sh 2>/dev/null || echo "NO /usr/bin/start-dumb-udev.sh"

echo
echo "=== relevant xorg-restart logic ==="
grep -nE "xorg-restarted|sunshine_inputs_present|sync_input_nodes|supervisorctl restart xorg|rm -f.*xorg-restarted|sleep 1" \
  /usr/bin/start-dumb-udev.sh 2>/dev/null || true

echo
echo "=== context around problematic block ==="
nl -ba /usr/bin/start-dumb-udev.sh 2>/dev/null \
  | sed -n "1,240p" \
  | grep -C 20 -E "xorg-restarted|supervisorctl restart xorg|sunshine_inputs_present|rm -f"

echo
echo "=== is local workaround applied? ==="
grep -n "true # disabled" /usr/bin/start-dumb-udev.sh 2>/dev/null || echo "not disabled"
'
=== does start-dumb-udev.sh exist? ===
-rwxr-xr-x 1 root root 493 Jun 24  2025 /usr/bin/start-dumb-udev.sh

=== relevant xorg-restart logic ===

=== context around problematic block ===

=== is local workaround applied? ===
not disabled

@atriusreal maybe you can copy/paste my command and post it's result? What is your environment (os, nvidia driver, docker run etc.)?

[thedotor]

I am using unraid,
got this setup a few days ago and not having this issue,

May 3 14:39:48 Blackhole-Serve kernel: traps: light-locker[552074] trap int3 ip:14a60375ea77 sp:7ffcdd587bd0 error:0 in libglib-2.0.so.0.8400.4[66a77,14a603717000+a1000]
May 3 14:39:50 Blackhole-Serve acpid: input device has been disconnected, fd 8
May 3 14:39:53 Blackhole-Serve kernel: input: Mouse passthrough as /devices/virtual/input/input152
May 3 14:39:53 Blackhole-Serve kernel: input: Mouse passthrough (absolute) as /devices/virtual/input/input153
May 3 14:39:53 Blackhole-Serve kernel: input: Keyboard passthrough as /devices/virtual/input/input154
May 3 14:39:53 Blackhole-Serve kernel: input: Sunshine Nintendo (virtual) pad as /devices/virtual/input/input155
May 3 14:39:53 Blackhole-Serve kernel: input: Sunshine X-Box One (virtual) pad as /devices/virtual/input/input156
May 3 14:39:53 Blackhole-Serve elogind-daemon[2751]: Watching system buttons on /dev/input/event4 (Keyboard passthrough)

is this the same problem as above ?

Nvidia Driver Version: 595.71.05
Detected via: nvidia-smi
Other dockers are able to use the graphics card without error.

Many thanks.

[pin00b]

@atassis @atriusreal I compared two josh5/steam-headless image digests on the same Unraid host.

Known-good / currently working container:

  Image reference:
    josh5/steam-headless@sha256:052f848563367016e88d9338e58899fe82399aa910a434474d7db378110fd2fe
  Image ID:
    sha256:745c50887778c6d973483ba67b3c776b9780755210ae8b8cdfa572166e34747c
  Status:
    Stable. Xorg, desktop, x11vnc, Sunshine, Steam Big Picture, Moonlight input, controller input, and Diablo IV all work.
  start-dumb-udev.sh:
    /usr/bin/start-dumb-udev.sh exists, but does NOT contain:
      - xorg-restarted
      - sunshine_inputs_present
      - sync_input_nodes
      - supervisorctl restart xorg
      - rm -f "${state_dir}/xorg-restarted"

Therefore, the xorg restart workaround/loop trigger is not present and no local sed workaround is active or required.

Current latest image tested separately:

Image reference:
   josh5/steam-headless:latest
 Repo digest after pull:
   sha256:a3324d9b1d5089f0088f9ab619b1ab051daec4e4a8043a886ae19f21f68d0277
 Image ID:
   sha256:ae2cc0a3d74d...
 start-dumb-udev.sh:
   /usr/bin/start-dumb-udev.sh is 2634 bytes and contains the problematic Xorg restart routine.

Relevant lines from latest:

40: sunshine_inputs_present() {
 70: while true; do
 71:     sync_input_nodes
 73:     if sunshine_inputs_present; then
 74:         if [[ ! -e "${state_dir}/xorg-restarted" ]]; then
 80:             sleep 2
 81:             sync_input_nodes
 82:             supervisorctl restart xorg >/dev/null 2>&1 || true
 83:             : > "${state_dir}/xorg-restarted"
 84:         fi
 85:     else
 86:         rm -f "${state_dir}/xorg-restarted"
 89:     sleep 1

This matches the suspected restart-loop mechanism: Sunshine input devices appear, start-dumb-udev.sh restarts Xorg and sets the xorg-restarted flag; restarting Xorg cascades into desktop/x11vnc/Sunshine being killed or restarted; Sunshine input devices temporarily disappear; the else branch clears xorg-restarted; when Sunshine respawns and devices appear again, Xorg is restarted again. This can create an infinite 6–7 second restart loop.

Important observation:
The currently working digest sha256:052f... does not contain this routine.
The current latest digest sha256:a332... does contain this routine.

Conclusion:
The crash-loop-prone Xorg restart logic was introduced after the known-good digest sha256:052f... and is present in the current latest digest sha256:a332...
My current stable setup is stable without any sed workaround because the problematic code path is absent entirely, not because it has been patched locally.

PS: content of my digest-specific start-dumb-udev.sh:

     1	#!/usr/bin/env bash
     2	###
     3	# File: start-dumb-udev.sh
     4	# Project: bin
     5	# File Created: Tuesday, 12th January 2022 8:46:47 am
     6	# Author: Josh.5 (jsunnex@gmail.com)
     7	# -----
     8	# Last Modified: Friday, 14th January 2022 9:21:00 am
     9	# Modified By: Josh.5 (jsunnex@gmail.com)
    10	###
    11	set -e
    12	
    13	# CATCH TERM SIGNAL:
    14	_term() {
    15	    kill -TERM "$dumb_udev_pid" 2>/dev/null
    16	}
    17	trap _term SIGTERM SIGINT
    18	
    19	
    20	# EXECUTE PROCESS:
    21	# Start dumb-udev
    22	dumb-udev &
    23	dumb_udev_pid=$!
    24	
    25	# WAIT FOR CHILD PROCESS:
    26	wait "$dumb_udev_pid"

start-dumb-udev.sh of current josh5/steam-headless:latest (causing crashloop):

     1	#!/usr/bin/env bash
     2	###
     3	# File: start-dumb-udev.sh
     4	# Project: bin
     5	# File Created: Tuesday, 12th January 2022 8:46:47 am
     6	# Author: Josh.5 (jsunnex@gmail.com)
     7	# -----
     8	# Last Modified: Friday, 14th January 2022 9:21:00 am
     9	# Modified By: Josh.5 (jsunnex@gmail.com)
    10	###
    11	set -e
    12	
    13	state_dir=/run/udev-input-fix
    14	
    15	# CATCH TERM SIGNAL:
    16	_term() {
    17	    kill -TERM "${sync_pid:-}" 2>/dev/null
    18	    kill -TERM "${dumb_udev_pid:-}" 2>/dev/null
    19	    kill -TERM "${udevd_pid:-}" 2>/dev/null
    20	}
    21	trap _term SIGTERM SIGINT
    22	
    23	sync_input_nodes() {
    24	    mkdir -p /dev/input
    25	
    26	    for sys in /sys/class/input/*/dev; do
    27	        [[ -f "${sys}" ]] || continue
    28	
    29	        node=$(basename "$(dirname "${sys}")")
    30	        path="/dev/input/${node}"
    31	        [[ -e "${path}" ]] && continue
    32	
    33	        IFS=: read -r major minor < "${sys}"
    34	        mknod "${path}" c "${major}" "${minor}" 2>/dev/null || continue
    35	        chmod 0660 "${path}" 2>/dev/null || true
    36	        chgrp input "${path}" 2>/dev/null || true
    37	    done
    38	}
    39	
    40	sunshine_inputs_present() {
    41	    for name_file in /sys/class/input/*/device/name; do
    42	        [[ -f "${name_file}" ]] || continue
    43	        case "$(cat "${name_file}" 2>/dev/null || true)" in
    44	            *passthrough*|Sunshine*)
    45	                return 0
    46	                ;;
    47	        esac
    48	    done
    49	    return 1
    50	}
    51	
    52	# EXECUTE PROCESS:
    53	# If a real udev daemon can be started in this restricted environment, prefer
    54	# that over dumb-udev. This gives us /run/udev/control and keeps the existing
    55	# Xorg startup ordering intact, even when /sys is mounted read-only.
    56	mkdir -p "${state_dir}"
    57	if command -v udevd &>/dev/null; then
    58	    unshare --net udevd --daemon &>/dev/null || true
    59	else
    60	    unshare --net /lib/systemd/systemd-udevd --daemon &>/dev/null || true
    61	fi
    62	
    63	if pgrep -x systemd-udevd >/dev/null 2>&1; then
    64	    udevd_pid=$(pgrep -xo systemd-udevd || true)
    65	fi
    66	
    67	dumb-udev &
    68	dumb_udev_pid=$!
    69	
    70	while true; do
    71	    sync_input_nodes
    72	
    73	    if sunshine_inputs_present; then
    74	        if [[ ! -e "${state_dir}/xorg-restarted" ]]; then
    75	            # Sunshine creates its virtual input devices on client connect. In
    76	            # restricted containers with a private /dev, the sysfs devices may
    77	            # exist before /dev/input/event* nodes are visible to Xorg. Build
    78	            # the missing nodes, then restart Xorg once so it enumerates them
    79	            # cleanly.
    80	            sleep 2
    81	            sync_input_nodes
    82	            supervisorctl restart xorg >/dev/null 2>&1 || true
    83	            : > "${state_dir}/xorg-restarted"
    84	        fi
    85	    else
    86	        rm -f "${state_dir}/xorg-restarted"
    87	    fi
    88	
    89	    sleep 1
    90	done &
    91	sync_pid=$!
    92	
    93	# WAIT FOR CHILD PROCESS:
    94	wait "$dumb_udev_pid"

[b3nis]

I have the same issue.

docker exec steam-headless sed -i 's|supervisorctl restart xorg|true # disabled|' /usr/bin/start-dumb-udev.sh
docker exec steam-headless supervisorctl restart udev

Does work for me as well as a work around.

[jamclucas]

i use truenas scale and a tesla p4 this is my fix

cat >/home/default/init.d/sunshine-stable-fix.sh <<'EOF'
#!/bin/bash

echo "[STEAM-HEADLESS FIX] disabling Xorg restart loop"

FILE="/usr/bin/start-dumb-udev.sh"

# backup
cp -n "$FILE" "$FILE.bak" 2>/dev/null || true

# disable ONLY the crash loop trigger
sed -i 's|supervisorctl restart xorg|echo "XORG RESTART DISABLED (stable mode)"|g' "$FILE"

# optional safety: prevent flag oscillation
sed -i 's|rm -f .*xorg-restarted|: # disabled|g' "$FILE"

# restart udev only (safe)
supervisorctl restart udev 2>/dev/null || true

echo "[STEAM-HEADLESS FIX] DONE - stable mode active"
EOF

chmod +x /home/default/init.d/sunshine-stable-fix.sh

bash /home/default/init.d/sunshine-stable-fix.sh

[jairbj]

Update: the fix below (netns removal + reactive node sync) turned out to still be racy — see the edit at the bottom for what actually closed it for good. Leaving the original bug reports intact since they're still accurate, just scroll to "Update: bug 3" for the real fix if you're only here for that.

---

Confirming the root cause @atassis described, plus a second, related bug that explains why some of us still get no mouse/keyboard/gamepad input via Moonlight even after disabling the supervisorctl restart xorg trigger.

Setup: Unraid, josh5/steam-headless:latest, NVIDIA Quadro P6000 (--runtime=nvidia), WEB_UI_MODE=vnc, ENABLE_SUNSHINE=true, ENABLE_EVDEV_INPUTS=true.

Bug 1 (the crash loop, same as #231): confirmed independently — sunshine_inputs_present() matches Sunshine's "Mouse/Keyboard passthrough" uinput devices, which exist from Sunshine's own startup, not from a client connecting. The else branch's rm -f "${state_dir}/xorg-restarted" fires on the brief gap created by Xorg's own restart killing/respawning Sunshine, re-arming the trigger and creating the infinite ~5s loop that takes desktop/x11vnc/Sunshine down with it.

Bug 2 (why input still doesn't work even with the restart disabled): in start-dumb-udev.sh, the real udevd/systemd-udevd fallback is launched as:

unshare --net udevd --daemon
# or
unshare --net /lib/systemd/systemd-udevd --daemon

unshare --net puts udevd into a new, empty network namespace. Kernel uevents (NETLINK_KOBJECT_UEVENT) are namespaced, and Sunshine (which creates the virtual input devices via /dev/uinput) runs in the container's normal/default network namespace. So udevd, sitting in its own isolated netns, never receives the live "add" uevent when Sunshine creates its devices — it only sees whatever existed via its own cold-plug scan at its own startup. Since Xorg's config/udev input backend listens for hotplug notifications relayed by udevd (not raw kernel uevents), it never learns about Sunshine's devices either, restart or no restart. This is on top of bug 1, not a replacement for it — even after disabling the Xorg-restart trigger, mouse/keyboard/gamepad stayed dead for me until I also fixed this.

Confirmed with udevadm monitor --udev --subsystem-match=input while restarting Sunshine:

• before the netns fix: no events at all when Sunshine's devices were recreated.
• after removing unshare --net: clean add/remove events show up immediately, and Xorg picks up the devices dynamically without ever needing a restart.

Fix that's been stable for me: (see update below — this closed bugs 1 & 2 but exposed a third race)

1. drop the whole sunshine_inputs_present/xorg-restarted/supervisorctl restart xorg block (per @atassis's "possible upstream fixes" — the restart isn't needed once bug 2 is also fixed), and
2. drop unshare --net from both udevd --daemon and /lib/systemd/systemd-udevd --daemon.

---

Update: bug 3, and the fix that's actually held up

The script from my first fix (reacting to udev events with a udevadm monitor watcher + a tight poll loop, both calling mknod) worked on the first container boot after deploying it, then intermittently broke mouse or keyboard again on later docker restarts. Root cause: /dev in this container is a plain tmpfs, not devtmpfs, so /dev/input/eventN nodes only exist once something userspace mknods them — udevd itself doesn't create them here. Once bug 2 was fixed, udevd started relaying Sunshine's device-add uevents to Xorg essentially instantly, and Sunshine creates all ~5-9 of its passthrough devices (mouse/keyboard/gamepad/pen/touch) in a single burst under ~30ms at startup. My watcher script and Xorg are two independent listeners reacting to the same uevent broadcast — for devices that close together, it's a straight foot race between my mknod and Xorg's open(), and Xorg's evdev driver does not retry a failed PreInit. No amount of shaving userspace reaction time (event-driven watcher instead of polling, line-buffering the pipe, making Sunshine wait a few seconds before it starts creating devices) fixed this reliably — I could always find a boot where at least one device lost the race. udevadm trigger --action=add would otherwise let Xorg retry after the fact, but that doesn't work here either: /sys is read-only in this container, and trigger needs to write to .../uevent.

The actual fix: stop reacting to the notification and make node creation part of producing it, via a RUN+= udev rule. udevd executes RUN+= commands synchronously inside its own worker for that device, and does not broadcast the event to monitor listeners (which is what Xorg's config/udev backend subscribes to) until every queued RUN command for it has finished. So mknoding via a rule instead of a separate watcher process makes it impossible for Xorg to see "device added" before the node exists — there's no longer two independent processes racing on the same event, just one pipeline. I verified this against the live rule engine with udevadm test /sys/class/input/eventN, which shows the RUN{program} queued with %k/%M/%m correctly substituted (e.g. event8 c 13 72).

Tested across 4 consecutive docker restarts with zero PreInit returned / Unable to open evdev device errors in the Xorg log (previously I could reproduce a failure within 1-2 restarts).

Full patched script:

#!/usr/bin/env bash
set -e
source /usr/bin/common-functions.sh

_term() {
    kill -TERM "${sync_pid:-}" 2>/dev/null
    kill -TERM "${monitor_pid:-}" 2>/dev/null
    kill -TERM "${dumb_udev_pid:-}" 2>/dev/null
    kill -TERM "${udevd_pid:-}" 2>/dev/null
}
trap _term SIGTERM SIGINT

sync_input_nodes() {
    mkdir -p /dev/input
    for sys in /sys/class/input/*/dev; do
        [[ -f "${sys}" ]] || continue
        node=$(basename "$(dirname "${sys}")")
        path="/dev/input/${node}"
        [[ -e "${path}" ]] && continue
        IFS=: read -r major minor < "${sys}"
        mknod "${path}" c "${major}" "${minor}" 2>/dev/null || continue
        chmod 0660 "${path}" 2>/dev/null || true
        chgrp input "${path}" 2>/dev/null || true
    done
}

mkdir -p /run/udev-input-fix

# Have udevd create /dev/input nodes itself, synchronously, as part of
# processing each device's add event -- before udevd broadcasts the event
# to Xorg. This is the actual fix for the race described above.
mkdir -p /run/udev/rules.d
cat > /run/udev/rules.d/99-input-node-fix.rules <<'RULES_EOF'
SUBSYSTEM=="input", KERNEL=="event*|mouse*|js*", RUN+="/bin/sh -c 'mkdir -p /dev/input; mknod -m 0660 /dev/input/%k c %M %m 2>/dev/null; chgrp input /dev/input/%k 2>/dev/null; true'"
RULES_EOF

if command -v udevd &>/dev/null; then
    udevd --daemon &>/dev/null || true
else
    /lib/systemd/systemd-udevd --daemon &>/dev/null || true
fi

if pgrep -x systemd-udevd >/dev/null 2>&1; then
    udevd_pid=$(pgrep -xo systemd-udevd || true)
fi

# Event-driven fallback: in case the rule above ever isn't picked up (e.g. a
# different udevd variant without RUN+= support), still react to live events.
if command -v udevadm &>/dev/null; then
    (
        stdbuf -oL udevadm monitor --udev --subsystem-match=input 2>/dev/null | \
        while IFS= read -r _; do
            sync_input_nodes
        done
    ) &
    monitor_pid=$!
fi

sync_input_nodes

dumb-udev &
dumb_udev_pid=$!

# Tight poll fallback, same reason as above.
while true; do
    sync_input_nodes
    sleep 0.2
done &
sync_pid=$!

wait "$dumb_udev_pid"

Notes on the rule:

• KERNEL=="event*|mouse*|js*" matches the same device name patterns the original sync_input_nodes() loop covered.
• %k/%M/%m are udev rule substitutions for kernel device name / major / minor.
• The rule is written to /run/udev/rules.d (not /etc) since that's the conventional location for boot-generated rules and doesn't need to survive a full container recreate — this script rewrites it on every start before udevd loads its rule set.
• I dropped the sunshine_inputs_present/xorg-restarted/Xorg-restart logic entirely (same as before) — it's not needed once nodes are created deterministically before Xorg ever sees the device.

Stable for me across multiple docker restarts now: Xorg/desktop/x11vnc/Sunshine all stay RUNNING, and mouse/keyboard/gamepad all work over Moonlight every time, without ever restarting Xorg after its initial boot.

If it's useful I'm happy to open a PR with this, just didn't want to assume the maintainers want the udevd namespacing removed / a new udev rule added without discussion.

[atassis]

I'll try to write in a month or two a new implementation of headless steam based on freedesktop stack (wayland and else). I already had a working prototype with patched Sunshine and other implemented things, but had issues with multiple containers running on single server (a container per gpu or even multiple container on single gpu)- they all share /dev/input stack so, for example, mouse control in first container is also moving mouse in second

[jaron-l]

Independent confirmation of the root cause and of @jairbj's RUN+= rule approach, tested on different hardware.

Setup: Unraid 7 (kernel 6.18.38), RTX 3060, NVIDIA driver 595.84 (--runtime=nvidia), host networking, ENABLE_SUNSHINE=true, josh5/steam-headless:latest (rebuilt 2026-08-01).

Before: the exact loop @atassis described — Xorg killed with SIGINT every ~5s, cascading into desktop (startxfce4: X server already running), x11vnc (exit 3), and Sunshine (exit 1/130), indefinitely. Confirmed the trigger was start-dumb-udev.sh re-arming via the else-branch rm -f "${state_dir}/xorg-restarted" during the gap its own restart created.

Fix tested: I cleaned up @jairbj's script into a committable change and built the image from source (Dockerfile.debian) with it:

• Drop unshare --net from the udevd launch (it was cutting udevd off from all kernel uevents — the reason the restart hack was needed at all)
• Remove the sunshine_inputs_present/xorg-restarted/supervisorctl restart xorg block entirely
• Ship the RUN+= mknod rule as a static file at /usr/lib/udev/rules.d/99-input-node-fix.rules instead of generating it into /run at runtime
• Keep sync_input_nodes as cold-plug coverage plus the 1s poll fallback; dropped the udevadm monitor watcher since the rule makes it redundant

Results:

• xorg / desktop / x11vnc / sunshine all hold RUNNING — through initial boot, multiple consecutive docker restarts, and extended uptime
• Zero PreInit returned / Unable to open evdev device errors in Xorg.55.log after every restart; all passthrough devices attach (XINPUT: Adding extended input device)
• udevadm test confirms the rule is loaded and queues the mknod with correct major/minor before the event is broadcast
• Steam remote play keyboard/mouse input and noVNC both work

Worth noting for the PR narrative: unshare --net, the sync loop, and the restart hack were all introduced together in 096fc4b — so removing the namespace isolation isn't undoing a long-standing design decision, it's fixing the same patch that caused this regression.

Branch with the change: https://github.com/jaron-l/docker-steam-headless/tree/fix/xorg-restart-loop — @jairbj, you offered to open a PR back in July; happy to defer to you since the approach is yours, or I can open one from this branch with credit to you and @atassis. Either way, this now has independent confirmation on a second Unraid/NVIDIA setup.

[bwonmp]

Third independent confirmation of bug 1, on a non-NVIDIA setup, plus a host-level gotcha that makes the RUN+= fix in @jairbj's update silently inert.

Setup: Unraid, josh5/steam-headless:latest (image built 2026-08-08), Intel iGPU / VA-API (iHD_drv_video.so), no NVIDIA runtime (runtime=runc, privileged, host networking), WEB_UI_MODE=vnc, ENABLE_SUNSHINE=true, ENABLE_EVDEV_INPUTS=true.

Bug 1 confirmed. Identical to @jaron-l's report, so the loop is not NVIDIA-specific — it reproduces with the modeset driver on an Intel iGPU. Xorg was SIGINTed every ~7s, cascading into x11vnc (exit 3), sunshine (exit 1) and desktop (exit 1) indefinitely, with Fatal server error: Server is already active for display 0 on the immediate respawn racing the stale /tmp/.X0-lock. Watching the guard file directly shows the re-arm @jairbj described:

t+1s: xorg-restarted
t+2s:                 <- sunshine down, else-branch rm -f wipes the guard
...
t+8s: xorg-restarted  <- fires again

Deleting only the else-branch rm -f "${state_dir}/xorg-restarted" was enough to stop the loop outright: Xorg went from dying every ~7s to stable, supervisord logged zero restart events, and xorg.err.log stopped growing (it had been writing ~1.7 MB/min).

The gotcha: udevd may never be running at all, which makes the RUN+= rule a no-op.

On this host no real udevd was running — only the dumb-udev Python relay. The launch in start-dumb-udev.sh fails silently because it's &>/dev/null || true. Run in the foreground, the reason appears:

# /lib/systemd/systemd-udevd
Failed to create inotify descriptor: Too many open files

That's the fs.inotify.max_user_instances cap (128, the Unraid default), not a file-descriptor limit — the wording sends you looking at the wrong resource.

Unraid doesn't use user-namespace remapping, so uid 0 inside every container shares the host's single uid-0 inotify budget. On a box with a lot of containers that budget is exhausted long before steam-headless starts, and udevd can never come up. udevadm test confirms the rule itself is correct and would work — it loads and queues with substitutions resolved (RUN{program} : /bin/sh -c '... mknod -m 0660 /dev/input/event3 c 13 67 ...', matching /sys/class/input/event3/dev = 13:67) — but with no udevd running there's no worker to execute it, so node creation silently falls back to the poll loop and the race @jairbj documented is still open.

Raising fs.inotify.max_user_instances to 1024 fixed it: udevd now starts normally, and udevadm test shows the rule's RUN{program} queued and executing. So @jairbj's fix is correct — it just can't engage at all on a host in this state, and there's nothing in the logs to say why.

Two suggestions, both cheap:

1. Don't swallow the udevd launch output — log the failure instead of &>/dev/null || true. It's the difference between a five-minute diagnosis and a long one, since every downstream symptom points at Xorg rather than at udevd never having started.
2. Worth a note in the docs that fs.inotify.max_user_instances may need raising on container-dense hosts, otherwise the RUN+= approach degrades to polling without any indication. On Unraid specifically, setting it in /boot/config/go is not sufficient — the Tips and Tweaks plugin runs later and resets it to 128 unless its own Max User Instances field is set.

Happy to test a PR on this hardware if that's useful — this setup seems to be a reasonable proxy for the non-NVIDIA / container-dense case.