### System details

Razer Blade 15 Advanced (Mid 2021) RZ09-0409, Intel i7-11800H, NVIDIA RTX 3070 Laptop (open module 610.57.04) + Intel TigerLake-H UHD, Omarchy 4.0.2-1, kernel 7.1.9-arch1-2, systemd 261.2-1, dbus 1.16.2 (dbus-daemon), glib2 2.88.3-1, Hyprland 0.56.2

### What's wrong?

#### Summary

`omarchy-system-sleep-monitor` uses `dbus-monitor --system` to watch for
`PrepareForSleep`. It runs in the user session, but new-style D-Bus monitoring
on the **system** bus is root-only, so every session start logs an
`AccessDenied` error and the tool silently falls back to legacy *eavesdropping*.

It works today. Eavesdropping is deprecated and slated for removal, so this is a
latent break as well as an error in the journal every boot.

#### What happens

```
omarchy-system-sleep-monitor[1572]: dbus-monitor: unable to enable new-style
monitoring: org.freedesktop.DBus.Error.AccessDenied: "Sender is not authorized
to send message". Falling back to eavesdropping.
```

Once per session start, reproducibly, on a clean install with no local
modifications to the unit or the script.

#### Expected

The sleep monitor subscribes to `PrepareForSleep` without requesting a
privilege it cannot hold, and without an error in the journal.

#### Root cause

`bin/omarchy-system-sleep-monitor` starts:

```bash
exec dbus-monitor --system \
  "type='signal',sender='org.freedesktop.login1',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'"
```

`dbus-monitor` first tries `org.freedesktop.DBus.Monitoring.BecomeMonitor`.
On the system bus that is root-only, per the shipped D-Bus policy
(`/usr/share/dbus-1/system.conf`):

```xml
<!-- root may monitor the system bus. -->
<policy user="root">
  <allow send_destination="org.freedesktop.DBus"
         send_interface="org.freedesktop.DBus.Monitoring"/>
</policy>
```

The script is launched under `systemd-inhibit` inside the user session
(uid 1000), so it can never satisfy that policy. `dbus-monitor` then falls back
to eavesdropping, which still works on dbus 1.16.2 but is deprecated.

The deeper point: **`PrepareForSleep` is a broadcast signal.** Receiving it
needs no monitoring privilege at all. Reaching for `dbus-monitor` — a debugging
tool that asks to see *all* traffic — requests far more authority than the task
needs.

#### Steps to reproduce

1. Boot Omarchy 4.0.2-1 and log in.
2. `journalctl -b 0 | grep sleep-monitor`

Or directly, as a normal user:

```console
$ dbus-monitor --system "type='signal',sender='org.freedesktop.login1',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'"
dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Sender is not authorized to send message". Falling back to eavesdropping.
```

The same command as root produces no warning, confirming it is purely the
privilege check:

```console
# dbus-monitor --system "type='signal',...,member='PrepareForSleep'"
(no stderr)
```

#### Impact

- **Today:** cosmetic. Lock-before-suspend works; the delay inhibitor is
  registered correctly (`systemd-inhibit --list` shows
  `Omarchy ... sleep ... Lock screen before suspend ... delay`).
- **Later:** when eavesdropping is removed from D-Bus, the fallback stops
  working and the monitor silently stops seeing `PrepareForSleep` — the screen
  would no longer lock before suspend, which is a security-relevant failure and
  would be hard to trace back to this.

#### Suggested fix

Use an ordinary signal-subscribing client instead of a bus monitor. `gdbus`
(already present via `glib2`) subscribes with no special privileges — verified
on this machine, no warning on stderr:

```console
$ gdbus monitor --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1
Monitoring signals on object /org/freedesktop/login1 owned by org.freedesktop.login1
```

**Caveat, so nobody takes this as a drop-in patch:** I verified that `gdbus`
*subscribes* cleanly, but not its `PrepareForSleep` output formatting. `gdbus`
renders signal arguments differently from `dbus-monitor`, so the parser in
`consume_sleep_events` — which matches on the literal string `boolean true` —
would need updating in the same change. I did not want to suggest an untested
one-liner that would quietly stop locking the screen.

Any ordinary D-Bus client works here; `gdbus` is just the one already on the
system. The maintainers are better placed than I am to pick the idiomatic
option for this codebase.

#### Related issues

Checked before filing; this is not a duplicate of any of them.

- **#10252** — same script, different defect: the lock starts *after*
  `PrepareForSleep(true)`, so `pam_fprintd` cannot get its own inhibitor. Worth
  noting that it quotes the very `*"boolean true"*` parser line that a fix here
  would have to change, so whoever touches that loop should look at both.
- **PR #10279** — in-flight change to this script (propagating sleep-lock exit
  status). Adjacent but independent; no conflict with what is proposed here.
- **#10255** — `omarchy-debug` output contains unredacted LAN IPs and MAC
  addresses. That is why no debug log is attached below.

##### Already sighted, never diagnosed

The warning has surfaced twice in other reports without being recognised as its
own defect:

- **#7316** (Intel Mac, slow wake) pastes a journal containing both halves of
  it, including the bus-side denial:

  ```
  dbus-broker[939]: A security policy denied :1.96 to send method call
    /org/freedesktop/DBus:org.freedesktop.DBus.Monitoring.BecomeMonitor
  omarchy-system-sleep-monitor[62357]: dbus-monitor: unable to enable new-style
    monitoring: org.freedesktop.DBus.Error.AccessDenied ...
  ```

  Worth noting that machine runs **dbus-broker** while mine runs
  **dbus-daemon 1.16.2** — so this is not implementation-specific, and not
  specific to my hardware.

- **#7811** lists it under "Possibly related observation" and sets it aside:
  *"the lock itself did engage, so this may be unrelated noise, but I'm
  including it for completeness."* That is exactly what this looks like from the
  outside — until eavesdropping goes away.

Neither issue is about this, and an exact-phrase search for
`"Falling back to eavesdropping"` returns no results, so I do not believe this
is a duplicate.

Diagnostics available on request. Deliberately not attached: on this machine the
`omarchy-debug` dump contains the host's MAC address, root-filesystem PARTUUID
and LAN addresses, per #10255.

*(Collected via `omarchy-debug --no-sudo --print` directly, since the `omarchy
debug` route is unreachable — already filed as #10258.)*

No screenshot attached: the bug has no visual manifestation, and the journal
excerpt above is the evidence.