## System details

Intel Core i5-5257U, Intel Iris Graphics 6100 (Broadwell-U), Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland/Wayland

## What's wrong?

`omarchy-system-sleep-monitor` exits with `status=1/FAILURE` and the unit logs `Failed with result 'exit-code'` on **every** sleep transition, because its restart races logind's sleep state change. `systemd-inhibit` cannot register a new delay inhibitor while logind is mid-sleep, so it exits 1, `Restart=always` retries 2s later, and the retry succeeds.

This is **cosmetic** — the lock-before-suspend path itself works correctly. Filing it because it puts a misleading `FAILURE` line in the journal on every suspend, plus restart-counter churn that looks alarming.

### Steps to reproduce

1. Suspend and resume (close and open the lid).
2. `journalctl --user -u omarchy-sleep-lock.service`
3. Observe one `status=1/FAILURE` per transition, then recovery on the next restart.

### The error

```
Sep 28 17:07:38.673147 omarchy systemd[828]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 7.
Sep 28 17:07:38.673762 omarchy systemd-logind[698]: Lid opened.
Sep 28 17:07:38.721249 omarchy kernel: ACPI: PM: Preparing to enter system sleep state S3
Sep 28 17:07:38.683507 omarchy systemd[828]: Started Lock Omarchy before suspend.
Sep 28 17:07:38.795875 omarchy systemd-inhibit[42152]: Failed to inhibit: The operation inhibition has been requested for is already running
Sep 28 17:07:38.799253 omarchy systemd[828]: omarchy-sleep-lock.service: Main process exited, code=exited, status=1/FAILURE
Sep 28 17:07:38.799955 omarchy systemd[828]: omarchy-sleep-lock.service: Failed with result 'exit-code'.
Sep 28 17:07:40.994981 omarchy systemd[828]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 8.
Sep 28 17:07:40.997079 omarchy systemd[828]: Started Lock Omarchy before suspend.
Sep 28 17:07:41.023750 omarchy-system-sleep-monitor[42431]: dbus-monitor: ...   <- healthy
```

### Root cause

The monitor is built to handle exactly one suspend per process — `consume_sleep_events` returns after the first `PrepareForSleep(boolean true)` event:

```bash
# /usr/share/omarchy/bin/omarchy-system-sleep-monitor
 7: consume_sleep_events() {
11:   while IFS= read -r line; do
12:     if [[ $line == *"boolean true"* ]]; then
13:       "$sleep_lock"
14:       return 0          # <-- exits after handling ONE suspend
15:     fi
16:   done
17: }
```

so it depends on systemd to bring it back:

```ini
# /usr/lib/systemd/user/omarchy-sleep-lock.service
Restart=always
RestartSec=2
```

The queued restart fires while logind is still in the sleep transition, so the `Inhibit()` D-Bus call is rejected and `systemd-inhibit` exits 1. `Restart=always` retries 2s later, when logind is idle, and succeeds.

### Evidence

- **31 of 31** `Failed to inhibit` events land within **2 seconds** of a suspend or resume (across 132 sleep transitions, all boots logged).
- Each suspend costs exactly two starts: one rejected, one healthy.
- The lock itself is unaffected. Before the suspend above, `omarchy-system-sleep-lock` secured the session in 557ms:
  ```
  16:46:11.225  omarchy lock lock-requested
  16:46:11.225  omarchy lock lock-pending: screen-stabilizing
  16:46:11.782  omarchy lock secure=true
  ```
- The `report_unsecured` path in `omarchy-system-sleep-lock` ("suspending without a secure lock") has fired **0 times** on this machine.

### Ruled out

Taking a second concurrent `systemd-inhibit --what=sleep --mode=delay` succeeds (exit 0), so this is not a duplicate-inhibitor rejection — it is logind refusing `Inhibit()` during an active sleep operation.

### Expected

The unit either stays up across sleep transitions, or the failed re-acquisition is retried internally without surfacing a `FAILURE` state. The delay inhibitor should not depend on a process restart at all.

### Possible fix

Have the monitor loop instead of exiting after one event, so the inhibitor is never released and re-acquired across a sleep transition. That removes the restart entirely and closes the (theoretical) ~2.3s window after each resume where a new sleep request is not delay-inhibited.

### Notes

The bug template asks for the output of `omarchy-debug`; that command does not exist in Omarchy 4.0.4 (`omarchy debug` returns `Unknown Omarchy command`, exit 127), so the evidence above is drawn straight from `journalctl`.