omarchy-update-user-notify.path used PathExistsGlob= on the packaged migrations directory. That directive is level-triggered: systemd re-checks it every time the triggered unit deactivates and fires again while the glob still matches. Since applied migrations stay on disk forever (state lives in ~/.local/state/omarchy/migrations), the glob always matches, so the oneshot notifier re-triggered itself in a tight loop (~26-66 starts/sec) — burning about a core and flooding the journal for the whole session. The loop existed since the unit was introduced, but the default start-rate limit killed it after 5 iterations, taking the .path unit down with 'unit-start-limit-hit'. That symptom was reported as #6174 and fixed yesterday by setting StartLimitIntervalSec=0 — which removed the only brake and turned the capped hiccup into an unbounded busy-loop. Fix the actual cause instead: * Drop PathExistsGlob= from the .path unit, keeping the edge-triggered PathModified= watch for updates that land mid-session. * Revert the StartLimitIntervalSec=0 override; with the level trigger gone there is no self-re-fire to trip the limit, and the default limit is a useful backstop again. * Preserve the once-per-login pending check the glob used to provide by giving the service its own WantedBy=graphical-session.target, enabled at first-run alongside the other user units. * Add a migration that daemon-reloads, revives a rate-limit-killed .path, restarts the watcher, and enables the login-time notifier on existing installs. Verified with transient path/service units: the old config runs the service 200 times in 3 seconds; the new config runs it zero times while idle and exactly once when a new migration file lands. Thanks to @HANCORE-Linux for finding and diagnosing the problem. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
21 lines
845 B
Bash
Executable File
21 lines
845 B
Bash
Executable File
#!/bin/bash
|
|
|
|
# Enable AND start the user systemd units we ship. Runs at first-run rather
|
|
# than at finalize-user time because the user manager isn't live during the
|
|
# ISO chroot — by first-run, the Hyprland/uwsm session is up and
|
|
# `systemctl --user enable --now` both writes the correct .wants symlinks
|
|
# (based on each unit's [Install]/WantedBy) and starts the services so the
|
|
# first session has bluetooth pairing, sleep lock, etc. live immediately
|
|
# instead of waiting for the next login. ConditionPath* in the unit files
|
|
# keep the enabled units inert on hardware they don't apply to.
|
|
|
|
set -euo pipefail
|
|
|
|
systemctl --user daemon-reload
|
|
systemctl --user enable --now \
|
|
bt-agent.service \
|
|
omarchy-recover-internal-monitor.service \
|
|
omarchy-sleep-lock.service \
|
|
omarchy-update-user-notify.path \
|
|
omarchy-update-user-notify.service
|