migrations/1785608166.sh: reset-failed on a never-loaded unit is fatal, stopping the update with a misleading error

[EttienneM]

System details

Apple MacBook Pro 16" M2 Pro (apple,j416s / apple,t6020), Asahi Linux, kernel 7.1.6-1-1-ARCH, omarchy-mac quattro at 95ffbc41 (v4.0.1-1-39-g95ffbc41).

Checkout install, not a package — /usr/share/omarchy is a root symlink to ~/.local/share/omarchy, OMARCHY_PATH is set in /etc/omarchy.conf, and no omarchy pacman package is installed (none exists for aarch64). Reached quattro via bin/omarchy-upgrade-to-quattro-mac.

What's wrong?

migrations/1785608166.sh runs systemctl --user reset-failed on a unit that may never have been loaded. reset-failed errors on an unknown unit, and the migration treats that as fatal — so the update stops with a message that names the wrong problem.

migrations/1785608166.sh:49-52

if [[ $graphical_state == "active" ]]; then
  if ! error=$(systemctl --user reset-failed omarchy-sleep-lock.service 2>&1); then
    echo "Could not reset omarchy-sleep-lock.service: $error"
    echo "The pre-suspend lock repair will be retried by omarchy-migrate."
    exit 1

What the user sees:

$ omarchy update
Running migration (1785608166)
Repair the pre-suspend lock monitor's graphical session environment
Could not reset omarchy-sleep-lock.service: Failed to reset failed state of unit
omarchy-sleep-lock.service: Unit omarchy-sleep-lock.service not loaded.
The pre-suspend lock repair will be retried by omarchy-migrate.
Something went wrong during the update!

"Could not reset" reads as a permissions or bus problem. The actual state is that the unit has never started, which is an entirely normal thing for reset-failed to encounter and nothing that needs repairing — there is no failed state to clear.

The same shape appears in the else branch at :74-77, after the stop.

Note that reset-failed is used correctly elsewhere in the tree: bin/omarchy-restart-audio:18 appends >/dev/null 2>&1 || true, which is exactly the treatment this call wants.

Suggested fix

Either tolerate the no-op:

systemctl --user reset-failed omarchy-sleep-lock.service >/dev/null 2>&1 || true

or gate on the unit being known before attempting it:

if systemctl --user list-unit-files omarchy-sleep-lock.service >/dev/null 2>&1; then
  ...
fi

Nothing downstream depends on reset-failed having succeeded — the restart that follows is what actually matters, and it works fine from a never-loaded state.

Two notes

This is not Apple Silicon-specific — it's inherited from basecamp/omarchy and would fire on x86 for any user whose sleep-lock unit has never started. Happy to file it upstream as well.

On my machine the unit was invisible for a different reason — /usr/lib/systemd/user/ is empty on a checkout install, which I've filed separately. But the two are independent: fixing the missing units makes this particular trigger go away, while reset-failed on a never-started unit remains fatal for anyone else who reaches it.

[duketopceo]

Fix up in #414 — went slightly further than the suggested || true: the migration now checks LoadState first and skips the live repair entirely when the unit is not-found (the #310 packaging gap means restart would fail too) or masked (don't force-start a unit the user disabled). Genuine restart/stop/inspection failures keep the retryable path.