### System details

- Omarchy 4.0.0-1 (stable)
- Arch Linux kernel 7.1.8-arch1-3
- systemd 261 (261.2-1-arch)
- dbus 1.16.2-1 / dbus-broker 37-3 (system bus)
- Homebrew (linuxbrew) 6.0.15 installed at /home/linuxbrew/.linuxbrew, with its
  bin/sbin prepended to $PATH ahead of /usr/bin (Homebrew's documented shellenv
  behavior)
- Stock omarchy-sleep-lock.service / omarchy-system-sleep-monitor, no local
  overrides

### What's wrong?

#### Summary

`omarchy-system-sleep-monitor` invokes `dbus-monitor` by bare name instead of an
absolute path:

    coproc SLEEP_EVENTS {
      exec dbus-monitor --system \
        "type='signal',sender='org.freedesktop.login1',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'"
    }

On a machine with Homebrew (linuxbrew) installed, Homebrew's `bin` directory
sits ahead of `/usr/bin` in `$PATH` — that's how `brew shellenv` is documented
to work. Homebrew ships its own `dbus` formula, and its `dbus-monitor` binary
is built with a relocatable default system-bus address baked in relative to
`$HOMEBREW_PREFIX` (`unix:path=$HOMEBREW_PREFIX/var/run/dbus/system_bus_socket`)
instead of the real system socket the OS actually uses
(`/run/dbus/system_bus_socket`, managed by dbus-broker here).

Because the script does a bare-name lookup, it silently runs Homebrew's
`dbus-monitor` instead of `/usr/bin/dbus-monitor`, which immediately fails to
connect and exits. `omarchy-sleep-lock.service` is `Type=simple` with
`Restart=always`/`RestartSec=2`, and because the script's `--inhibited` branch
always ends with an explicit `exit 0` regardless of `dbus-monitor`'s outcome,
systemd just restarts it again every 2 seconds, forever. The unit never enters
a permanent "failed" state, so nothing surfaces this; it just quietly never
watches for `PrepareForSleep` at all.

Net effect: the pre-suspend lock (the entire purpose of this service) never
fires on this class of machine, and the session accumulates tens of thousands
of restart cycles.

#### Evidence

    $ systemctl --user show omarchy-sleep-lock.service -p NRestarts,SubState
    NRestarts=10543
    SubState=auto-restart

    $ journalctl --user -u omarchy-sleep-lock.service | tail
    ...
    omarchy-system-sleep-monitor[...]: Failed to open connection to system bus: Failed to connect to socket /home/linuxbrew/.linuxbrew/var/run/dbus/system_bus_socket: No such file or directory

    $ which -a dbus-monitor
    /home/linuxbrew/.linuxbrew/bin/dbus-monitor     # resolves first, this is what actually runs
    /usr/bin/dbus-monitor                            # the correct one, shadowed
    $ readlink -f /home/linuxbrew/.linuxbrew/bin/dbus-monitor
    /home/linuxbrew/.linuxbrew/Cellar/dbus/1.16.2_1/bin/dbus-monitor

The restart counter climbs roughly once per `RestartSec` (2s) continuously
since the graphical session started — over 10,000 restarts in a ~6 hour
session — and never stabilizes.

#### Expected result

The sleep monitor should reliably watch the real system D-Bus for
`PrepareForSleep` and lock the screen before every suspend, regardless of what
else is on the user's `$PATH`.

#### Actual result

`omarchy-system-sleep-monitor` runs whichever `dbus-monitor` happens to
resolve first on `$PATH`. If a non-system one shadows it — Homebrew/Linuxbrew
is one concrete case, but any self-contained `dbus-monitor` build with a
different compiled-in default bus address would trigger the same failure —
the monitor can never connect, and the unit restart-loops indefinitely without
ever reporting a hard failure.

#### Impact

- The pre-suspend screen lock feature is completely non-functional on
  affected machines — silently, since the unit never shows as "failed".
- `omarchy-sleep-lock.service` restarts every 2 seconds indefinitely for the
  entire session: small but continuous CPU/log churn, and it makes the
  journal much noisier when debugging anything else sleep-related.
- Distinct from #7280: that one is a self-healing ~2s gap tied to actual
  suspend/resume timing. This one never self-heals — the daemon can't work at
  all as long as the PATH shadowing is in place, and it is unrelated to
  resume timing.

#### Reproduction

1. Install Homebrew on Linux (linuxbrew) with its default shell integration
   (`eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"`), which prepends
   its bin/sbin to $PATH — Homebrew's documented setup.
2. Ensure Homebrew's `dbus` formula is installed (pulled in as a dependency by
   several formulae).
3. Start a graphical session so `omarchy-sleep-lock.service` runs.
4. `which -a dbus-monitor` shows the Homebrew path first.
5. `journalctl --user -u omarchy-sleep-lock.service -f` shows a continuous
   "Failed to open connection to system bus: ... No such file or directory"
   restart loop.

#### Possible directions (not tested — offered as a starting point)

1. Call `dbus-monitor` by absolute path (`/usr/bin/dbus-monitor`) in
   `omarchy-system-sleep-monitor`. Minimal, targeted fix.
2. Alternatively, use `gdbus monitor` or a small helper linked against the
   system libdbus rather than shelling out to a $PATH-resolved binary at all.
3. Regardless of the fix, consider having the script treat a
   persistently-failing `dbus-monitor` connection as a hard failure rather
   than an unconditional `exit 0`, so this doesn't fail silently for a
   different underlying reason next time.

I have not implemented or tested any of these, so treat them as suggestions
rather than proposals.

---

Filed by Claude Sonnet 5 via Claude Code CLI.