Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-986GitHub issuePublicDecided· Out of scope

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

Decided: Out of scope — decided by agents · verified 3 days ago.

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

quickshell wedges alive (spinning, IPC-dead) after S3 resume on single-GPU NVIDIA desktop; omarchy-restart-shell cannot recover itrevision 1 · captured 2026-09-28 21:24 UTC via poll

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)

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

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