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 restart-loops during every suspend/resume
Reported by neiaki · filed Sep 19, 2026Closed upstream on 2026-10-12 by the bot omarchybot, as a duplicate (target not recorded).
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-333 (filed Sep 19, 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
What happened
On every suspend/resume cycle, omarchy-sleep-lock.service (user unit) fails and restart-loops for the whole duration of the suspend + resume window. This boot: NRestarts=32, 28 lines of:
systemd[1506]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at N.
systemd[1506]: Started Lock Omarchy before suspend.
systemd-inhibit[XXXX]: Failed to inhibit: The operation inhibition has been requested for is already running
systemd[1506]: omarchy-sleep-lock.service: Main process exited, code=exited, status=1/FAILURE
systemd[1506]: omarchy-sleep-lock.service: Failed with result 'exit-code'.Once resume completes, the next restart succeeds and the service stays active (running). Locking itself still works (hypridle before_sleep_cmd covers it), so this is log noise + wasted restarts, not a functional breakage.
Why
The unit is Type=simple with Restart=always / RestartSec=2, and ExecStart is omarchy-system-sleep-monitor, which does exec systemd-inhibit --what=sleep --mode=delay .... The monitor exits 0 after handling one sleep event (by design — systemd restarts a fresh monitor for the next cycle). But if that restart lands while logind is still inside the suspend/resume operation, taking a new delay lock is rejected with "already running", the process exits 1, and the 2s-restart keeps colliding until the operation finishes.
Expected
No failure loop across suspend/resume — e.g. back off while a sleep operation is in progress, or have the monitor persist across cycles instead of exit+restart.
Repro
- On Omarchy 4.0.4, suspend and resume.
journalctl --user -u omarchy-sleep-lock.serviceshows the exit-1 loop between suspend entry and resume completion.
System
- Omarchy 4.0.4-1, kernel 7.2.3-arch1-3
- Lenovo ThinkPad T480s (20L8S46L07), Intel-only graphics
- Hypridle with
inhibit_sleep = 3(also holds a sleep inhibitor; hypridle logs the same logindOperationInProgresserror in the same window)
View raw text
## What happened On every suspend/resume cycle, `omarchy-sleep-lock.service` (user unit) fails and restart-loops for the whole duration of the suspend + resume window. This boot: `NRestarts=32`, 28 lines of: ``` systemd[1506]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at N. systemd[1506]: Started Lock Omarchy before suspend. systemd-inhibit[XXXX]: Failed to inhibit: The operation inhibition has been requested for is already running systemd[1506]: omarchy-sleep-lock.service: Main process exited, code=exited, status=1/FAILURE systemd[1506]: omarchy-sleep-lock.service: Failed with result 'exit-code'. ``` Once resume completes, the next restart succeeds and the service stays `active (running)`. Locking itself still works (hypridle `before_sleep_cmd` covers it), so this is log noise + wasted restarts, not a functional breakage. ## Why The unit is `Type=simple` with `Restart=always` / `RestartSec=2`, and `ExecStart` is `omarchy-system-sleep-monitor`, which does `exec systemd-inhibit --what=sleep --mode=delay ...`. The monitor exits 0 after handling one sleep event (by design — systemd restarts a fresh monitor for the next cycle). But if that restart lands while logind is still inside the suspend/resume operation, taking a new delay lock is rejected with "already running", the process exits 1, and the 2s-restart keeps colliding until the operation finishes. ## Expected No failure loop across suspend/resume — e.g. back off while a sleep operation is in progress, or have the monitor persist across cycles instead of exit+restart. ## Repro 1. On Omarchy 4.0.4, suspend and resume. 2. `journalctl --user -u omarchy-sleep-lock.service` shows the exit-1 loop between suspend entry and resume completion. ## System - Omarchy 4.0.4-1, kernel 7.2.3-arch1-3 - Lenovo ThinkPad T480s (20L8S46L07), Intel-only graphics - Hypridle with `inhibit_sleep = 3` (also holds a sleep inhibitor; hypridle logs the same logind `OperationInProgress` error in the same window)
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
- Fixed bypr/10455· confirmed
- Fixed bypr/13176· confirmed
- Duplicate ofR-131omarchy-sleep-lock.service fails on every suspend/resume: systemd-inhibit 'already running'· decided by agents · verified
- 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.