Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
quickshell wedges alive (spinning, IPC-dead) after S3 resume on single-GPU NVIDIA desktop; omarchy-restart-shell cannot recover it
Reported by noahkrueger · filed Sep 4, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Omarchy 4.0.2-1, Quickshell 0.3.1-1, Hyprland 0.56.2-1, qt6-wayland 6.11.2-1,
nvidia-open-dkms / nvidia-utils 610.57.04-1, linux 7.1.9.arch1-2.
AMD Ryzen 7 7700X, RTX 4070 SUPER (AD104), single monitor — LG DP-3
3840x1600@144, Wayland, uwsm session, nvidia_drm modeset=1.
Note this is a single-GPU, single-DP desktop, which distinguishes it from
the multi-DP laptop reports below.
What's wrong?
After a resume from deep S3, quickshell survives but wedges: the process
stays alive in R state spinning ~1.7% CPU, stops answering IPC
(omarchy-shell is not responding), and leaves its stale full-screenomarchy-background layer composited over everything. The visible result is a
desktop that looks like nothing but wallpaper and a cursor — Hyprland and all
client windows are actually fine underneath, just covered.
This is distinct from #9549 / #7380 / #8453, where the shell dies with a
fatal Wayland protocol error and relaunches. Here there is no fatal error and
no exit — it just stops responding, so the supervision path never triggers.
`omarchy restart shell` cannot recover it. The wedged PID does not exit, so
the replacement instance aborts with `An instance of this configuration is
already running and the command reports Omarchy shell did not become ready
after restart. Only kill -9` clears it.
Timeline (journalctl, resume at 20:40:28)
20:40:28.665894 systemd[1181]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 1.
20:40:28.667151 kernel: ACPI: PM: Preparing to enter system sleep state S3
20:40:28.668453 kernel: ACPI: PM: Waking up from system sleep state S3
20:40:28.672623 kernel: [drm:__nv_drm_semsurf_wait_fence_work_cb [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to register auto-value-update on pre-wait value for sync FD semaphore surface
20:40:28.688019 systemd-inhibit[59431]: Failed to inhibit: The operation inhibition has been requested for is already running
20:40:28.688257 systemd[1181]: omarchy-sleep-lock.service: Main process exited, code=exited, status=1/FAILURE
20:40:29.669358 kernel: PM: suspend exit
20:40:29.728147 omarchy-shell[1386]: WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked.
20:40:30.795678 systemd[1181]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 2.The nvidia-drm sync-FD semaphore failure lands ~1s before quickshell'sFALLBACK monitor warning. After that warning the shell never responds again.
Steps to reproduce
Not reliably reproducible — observed once, on the first suspend of this
install. Conditions:
- Single-GPU NVIDIA desktop (open modules), single DP monitor, uwsm/Hyprland.
- Suspend to deep S3. In this instance suspend was invoked as a detached
systemctl suspend from a background shell rather than via the Omarchy menu,
which is likely why omarchy-sleep-lock restarted mid-operation.
3. Resume after several hours.
Recovery that works
kill -9 $(pgrep -x quickshell)
setsid nohup omarchy-shell-start >/dev/null 2>&1 &Layers (omarchy-background, omarchy-bar, omarchy-notifications) re-register
immediately and the desktop is normal again. No reboot needed.
Suggested handling
omarchy-restart-shell currently assumes the old instance will exit on request.
A wedged-but-alive instance defeats that. A bounded escalation — wait briefly for
a clean exit, then SIGKILL before starting the replacement — would turn this
from "desktop unusable, reboot" into a one-command recovery.
Related
- #7280, #8112 — the
omarchy-sleep-lock"inhibition already running" failure
visible in the timeline above. Already reported; not the subject of this issue,
but it co-occurs and is why the session also resumed unlocked.
- #9549, #7380, #8453 — shell killed by a fatal Wayland error on NVIDIA multi-DP.
Same component, different failure mode (dies vs. wedges).
- #9308 — internal panel black after wake, dpmsStatus desync. DPMS was 1
(on) throughout here; the cover was the stale layer, not a blank panel.
Filed by Claude Opus 5 via Claude Code.
View raw text
### System details Omarchy 4.0.2-1, Quickshell 0.3.1-1, Hyprland 0.56.2-1, qt6-wayland 6.11.2-1, nvidia-open-dkms / nvidia-utils 610.57.04-1, linux 7.1.9.arch1-2. AMD Ryzen 7 7700X, **RTX 4070 SUPER (AD104), single monitor** — LG DP-3 3840x1600@144, Wayland, uwsm session, `nvidia_drm modeset=1`. Note this is a **single-GPU, single-DP desktop**, which distinguishes it from the multi-DP laptop reports below. ### What's wrong? After a resume from deep S3, `quickshell` **survives but wedges**: the process stays alive in `R` state spinning ~1.7% CPU, stops answering IPC (`omarchy-shell is not responding`), and leaves its stale full-screen `omarchy-background` layer composited over everything. The visible result is a desktop that looks like nothing but wallpaper and a cursor — Hyprland and all client windows are actually fine underneath, just covered. This is distinct from #9549 / #7380 / #8453, where the shell **dies** with a fatal Wayland protocol error and relaunches. Here there is no fatal error and no exit — it just stops responding, so the supervision path never triggers. **`omarchy restart shell` cannot recover it.** The wedged PID does not exit, so the replacement instance aborts with `An instance of this configuration is already running` and the command reports `Omarchy shell did not become ready after restart.` Only `kill -9` clears it. ### Timeline (journalctl, resume at 20:40:28) ```text 20:40:28.665894 systemd[1181]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 1. 20:40:28.667151 kernel: ACPI: PM: Preparing to enter system sleep state S3 20:40:28.668453 kernel: ACPI: PM: Waking up from system sleep state S3 20:40:28.672623 kernel: [drm:__nv_drm_semsurf_wait_fence_work_cb [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to register auto-value-update on pre-wait value for sync FD semaphore surface 20:40:28.688019 systemd-inhibit[59431]: Failed to inhibit: The operation inhibition has been requested for is already running 20:40:28.688257 systemd[1181]: omarchy-sleep-lock.service: Main process exited, code=exited, status=1/FAILURE 20:40:29.669358 kernel: PM: suspend exit 20:40:29.728147 omarchy-shell[1386]: WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked. 20:40:30.795678 systemd[1181]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 2. ``` The `nvidia-drm` sync-FD semaphore failure lands ~1s before quickshell's `FALLBACK` monitor warning. After that warning the shell never responds again. ### Steps to reproduce Not reliably reproducible — observed once, on the first suspend of this install. Conditions: 1. Single-GPU NVIDIA desktop (open modules), single DP monitor, uwsm/Hyprland. 2. Suspend to deep S3. In this instance suspend was invoked as a detached `systemctl suspend` from a background shell rather than via the Omarchy menu, which is likely why `omarchy-sleep-lock` restarted mid-operation. 3. Resume after several hours. ### Recovery that works ```bash kill -9 $(pgrep -x quickshell) setsid nohup omarchy-shell-start >/dev/null 2>&1 & ``` Layers (`omarchy-background`, `omarchy-bar`, `omarchy-notifications`) re-register immediately and the desktop is normal again. No reboot needed. ### Suggested handling `omarchy-restart-shell` currently assumes the old instance will exit on request. A wedged-but-alive instance defeats that. A bounded escalation — wait briefly for a clean exit, then `SIGKILL` before starting the replacement — would turn this from "desktop unusable, reboot" into a one-command recovery. ### Related - #7280, #8112 — the `omarchy-sleep-lock` "inhibition already running" failure visible in the timeline above. Already reported; not the subject of this issue, but it co-occurs and is why the session also resumed unlocked. - #9549, #7380, #8453 — shell killed by a *fatal Wayland error* on NVIDIA multi-DP. Same component, different failure mode (dies vs. wedges). - #9308 — internal panel black after wake, `dpmsStatus` desync. DPMS was `1` (on) throughout here; the cover was the stale layer, not a blank panel. Filed by Claude Opus 5 via Claude Code.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 10:44 UTC