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.
omarchy-sleep-lock.service fails intermittently on repeated suspend/resume cycles ("inhibition already running")
Reported by bryansiegel · filed Aug 24, 2026 · open at source
This defect is tracked under R-131. This report describes the same defect, so it is folded under it in the inbox.
Earliest report of this defect: R-1496 (filed Aug 24, 2026).
Decided by agents · verified· Oct 9, 2026
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?
- 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
omarchy-sleep-lock.service fails intermittently on repeated suspend/resume cycles ("inhibition already running")
On repeated suspend/resume cycles in a short window (e.g. closing/opening a laptop lid several times), omarchy-sleep-lock.service reliably fails with:
systemd-inhibit: Failed to inhibit: The operation inhibition has been requested for is already runningDigging into it, the mechanism looks like this: omarchy-system-sleep-monitor acquires one delay-inhibitor, waits for a single PrepareForSleep(true) dbus signal, calls omarchy-system-sleep-lock, then exits. It relies on Restart=always/RestartSec=2 to respawn and re-acquire a fresh inhibitor before the next suspend. But real-clock RestartSec freezes during suspend and fires right on resume — a fast second suspend can beat the respawn, so that cycle proceeds uninhibited, and the eventually-restarted instance's systemd-inhibit call lands after logind has already moved past accepting a new inhibitor for that transition. Widening the restart delay (tried 0.5s and 2s) didn't fix it — it looks like a structural issue with the respawn-per-cycle design racing suspend duration itself, not a timing constant to tune.
Repro: close/reopen a laptop lid (or otherwise trigger systemd-sleep) several times in quick succession, then check journalctl --user -u omarchy-sleep-lock.service for status=1/FAILURE restarts.
View raw text
`omarchy-sleep-lock.service` fails intermittently on repeated suspend/resume cycles ("inhibition already running")
On repeated suspend/resume cycles in a short window (e.g. closing/opening a laptop lid several times), `omarchy-sleep-lock.service` reliably fails with:
```
systemd-inhibit: Failed to inhibit: The operation inhibition has been requested for is already running
```
Digging into it, the mechanism looks like this: `omarchy-system-sleep-monitor` acquires one delay-inhibitor, waits for a single `PrepareForSleep(true)` dbus signal, calls `omarchy-system-sleep-lock`, then exits. It relies on `Restart=always`/`RestartSec=2` to respawn and re-acquire a fresh inhibitor before the next suspend. But real-clock `RestartSec` freezes during suspend and fires right on resume — a fast second suspend can beat the respawn, so that cycle proceeds uninhibited, and the eventually-restarted instance's `systemd-inhibit` call lands after logind has already moved past accepting a new inhibitor for that transition. Widening the restart delay (tried 0.5s and 2s) didn't fix it — it looks like a structural issue with the respawn-per-cycle design racing suspend duration itself, not a timing constant to tune.
Repro: close/reopen a laptop lid (or otherwise trigger `systemd-sleep`) several times in quick succession, then check `journalctl --user -u omarchy-sleep-lock.service` for `status=1/FAILURE` restarts.
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
- Duplicate ofR-131omarchy-sleep-lock.service fails on every suspend/resume: systemd-inhibit 'already running'· decided by agents · verified
- Related PRpr/10455· confirmed
- Fixed bypr/13176· confirmed
- Fixed bypr/13782· confirmed
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.