## System details

Omarchy 4.0.0-1 · Hyprland 0.56.2 · quickshell 0.3.0.r20.g28771c7-1 · Arch Linux
QEMU/KVM VM with iGPU passthrough: AMD Ryzen 7 8745H (Radeon 780M) driving a ViewSonic VX2880-4K over DP-2, single monitor.

## What's wrong?

After locking, the display never powers off. The lock service's 5-second blank (`idleBlankTimer` → `runBlank()` in `shell/plugins/lock/Service.qml`) silently does nothing once the shell process has been running for a long time (~24h in my case). `runWake()` uses the same spawn pattern, so the worse variant of this bug — a display that won't come back on input — is latent in the same code path.

What I verified on the failing shell, the same day it was wedged:

- Locked via `omarchy-shell lock lock` and polled `hyprctl monitors -j`: `dpmsStatus` stayed `true` at +7.5s, +35s, and minutes later.
- Idle behavior was otherwise healthy: the screensaver fired at 150s and lock at 300s on schedule all day (journal), and Quickshell `Process` spawns from the idle service (screensaver / lock / wake) kept working.
- The blank command chain works from every context I could run it: a login shell, the shell process's exact environment (`/proc/<pid>/environ`), and while the session is locked (the display stays off — nothing re-enables DPMS underneath the lock surface).
- No input occurred during the failing window (the Quickshell idle monitor still fired on schedule), so it is not pointer jitter re-arming the timer.
- `beginLock()` completed — the `lock-requested` journal event logs only after `armBlankTimer()` has run.

Minimal reproduction in a fresh process (works): I extracted the exact pattern — `Timer { interval: 5000 }` with the suspend freeze-guard, plus a `Process { command: ["bash", "-c", "omarchy-brightness-keyboard off; omarchy-brightness-display off"] }` started via `running = true` — into a standalone quickshell instance. The timer fired at 5284ms, the process spawned, and the display blanked and restored. The pattern itself is fine in a fresh process; only the long-running shell fails.

Suspected mechanism: a Quickshell `Process` whose child exit was missed leaves `running == true`, after which the `if (!process.running)` guard in `runBlank()` / `runWake()` silently skips every later spawn until the shell is restarted. I could not observe the property directly (it is not exposed over IPC), but every other link in the chain is verified working, and the failure was permanent across many locks until restart.

Recovery: `omarchy restart shell` restores blanking — `dpmsStatus` went `false` at lock+5s right after a restart and stayed off (verified twice).

Local mitigation: I cloned the lock service via `omarchy plugin clone omarchy.lock` and switched `runBlank`/`runWake` to stateless `Quickshell.execDetached([...])` plus one idempotent retry 5s later (cancelled by any wake interaction). The journal now shows `blank-display` and `blank-display-retry` events exactly at lock+5s/+10s.

Suggestions:

- Spawn blank/wake statelessly (`Quickshell.execDetached`) or create a fresh `Process` per run instead of guarding on a reused `running` property.
- A `logEvent` line in `runBlank()` would make this class of silent failure visible in the journal.

Debug log: https://logs.omarchy.org/lWKPEB