# `omarchy update` can leave the Omarchy shell dead for the rest of the session

## Summary

After `omarchy update` completed, the Omarchy shell never came back. The bar was
gone, no menu would open (Omarchy menu, Apps, System, Power, Theme), and every
keybinding bound to a menu did nothing. Hyprland itself was healthy, so the
session looked alive but was unusable until `omarchy restart shell` was run by
hand.

## Timeline

```
Oct 02 10:09:04 omarchy uwsm_app-daemon[954]: received: app -- xdg-terminal-exec --app-id=org.omarchy.terminal --title=Omarchy -e bash -c 'omarchy-show-logo; omarchy-update; if (( $? != 130 )); then omarchy-show-done; fi'
Oct 02 10:09:09 omarchy sudo[2376]:      wjl : ... COMMAND=/usr/bin/snapper -c root create -c number -d 4.0.4-1
Oct 02 10:09:20 omarchy sudo[2811]:      wjl : ... COMMAND=/usr/bin/env LC_ALL=C OMARCHY_UPDATE_PACMAN=1 pacman -Syu --noconfirm --overwrite /usr/share/omarchy/*
Oct 02 10:09:26 omarchy sudo[2454]: pam_unix(sudo:session): session closed for user root
Oct 02 10:09:28 omarchy omarchy-shell[931]:  INFO: Exiting due to IPC request.
Oct 02 10:09:34 omarchy omarchy-shell[3248]: An instance of this configuration is already running.
```

The last line is Quickshell refusing the replacement instance because the
previous one had not finished releasing its single-instance lock. Six seconds
after being told to exit, the old instance was still tearing down.

## State measured afterwards

- no `quickshell` process alive
- no `omarchy-launch-shell` supervisor alive
- `hyprctl layers` had no `omarchy-bar` layer (only the Hyprland layer tree)
- stale singleton artifacts left in tmpfs:

```
/run/user/1000/quickshell/by-id/vpkmc9mt/instance.lock
/run/user/1000/quickshell/by-id/vpkmc9mt/ipc.sock
/run/user/1000/quickshell/by-pid/931 -> /run/user/1000/quickshell/by-id/vpkmc9mt
```

Everything else was fine, which is what makes this state confusing:

- `hyprctl configerrors` -> empty
- 228 bindings loaded, all `dispatcher: __lua`
- 0 failed systemd units (system and user scope)
- `pacman -Qkk omarchy` -> `1730 total files, 0 altered files`

The menu bindings stopped working because they are implemented by the shell
process. With the shell dead they silently became no-ops, so the keybindings
themselves were intact.

## The supervisor never retried

`omarchy-launch-shell` wraps quickshell in a retry loop that logs

```
logger -t omarchy-shell "Omarchy shell exited with status $status; relaunching."
logger -t omarchy-shell "Giving up on the Omarchy shell after $attempts relaunches in under a minute."
```

Neither line was ever emitted:

```
$ journalctl --user -b -t omarchy-shell --no-pager | grep -icE "relaunch|giving up"
0
```

So the one refused launch was terminal for the session. This is the part that
turns a transient collision into a broken desktop.

## Contributing assumption that does not hold

`omarchy-update` ends with:

```bash
# Updates routinely replace the shell's QML, and a stale process can lazy-load
# new files into old code. A restart failure (locked session, ssh, TTY) only
# prints its reason: the next update or login gets a fresh shell anyway.
echo -e "\e[32m\nRestarting shell\e[0m"
echo "All plugins have been reloaded"
omarchy-restart-shell || true
```

The comment assumes a failed restart is harmless because the next update or
login gets a fresh shell. In this case there is no next login: the session
continues with no bar until the user logs out. `|| true` additionally discards
the only signal that anything went wrong, so `omarchy update` reports success
while the desktop is broken.

## Steps to reproduce

1. Log into a normal Omarchy Hyprland session with the shell running under
   `omarchy-launch-shell`.
2. Run `omarchy update`.
3. If the update's shell restart lands while the previous instance is still
   tearing down, the replacement quickshell is refused by the Quickshell
   single-instance lock and exits immediately.
4. No bar, no menus, menu keybindings inert, until logout.

The collision window is narrow (6s between the IPC exit and the refused
replacement here), so this should be intermittent rather than deterministic.

## Workaround

`omarchy restart shell` recovers the session. Be aware that it currently
reports failure even when it succeeds; see the companion report.

## System

- Omarchy `4.0.4-1`
- kernel `7.2.5-3-omarchy`, systemd 261
- Hyprland `0.56.2-2`, quickshell `0.3.1-1`
- GPU: NVIDIA GeForce 610M (GF108M) on nouveau, driver in use `nouveau`
- Lenovo B340 AIO, Intel Celeron G1610

## Diagnostics

`/usr/bin/omarchy-debug --no-sudo --print` output attached. Note that its
JOURNALCTL section only includes warnings and errors, so it does not contain the
two `INFO` lines quoted above; those came from
`journalctl --user -b -t omarchy-shell --no-pager`.