System details
Omarchy 4.0.2-1, Quickshell 0.3.1-1, Hyprland 0.56.2-1, 1password 8.12.34-35, linux 7.1.9-arch1-2.
Laptop, hybrid GPU: Intel CometLake-H UHD (i915, eDP-1) + NVIDIA GTX 1650 Mobile (nvidia-open-dkms). Single internal display, no external monitor. Wayland, uwsm session.
What's wrong
Twice in one night, quickshell wedged while the session was idle-locked. The process stayed alive and its IPC kept answering, but it stopped logging entirely and its ext-session-lock client died — leaving Hyprland's crashed-lockscreen failsafe on screen until morning.
The dangerous part is that IPC keeps serving the lock state the shell last reached, so the shell reports a healthy, secure lock long after its locker is gone:
$ omarchy-shell lock status
{"locked":true,"requested":true,"pending":false,"sessionLocked":true,
"secure":true,"realScreens":1,...,"lastEvent":"secure=true",
"lastEventAt":"2026-09-06T16:02:06.569Z"} <- 4h39m stale
omarchy-restart-shell then refuses to recover it. Its guard reads exactly that status to decide whether a live locker is worth preserving:
Refusing to restart Omarchy shell while the session is locked.
So the documented way out of the failsafe is blocked by the very state it exists to clear. The wedge is in the event loop, not the IPC thread, so a dead locker is indistinguishable from a healthy one over IPC. Short of patching a copy of the script, the only way back in is a reboot.
Occurrences
Both times: shell alive, solitaryBlockedBy contains LOCK, zero log lines afterwards.
|
locked at |
last log line |
silent for |
shell PID |
| 1 |
20:14:16 |
20:36:43 |
5h16m |
20183 |
| 2 |
02:02:06 |
02:13:08 |
4h39m |
267461 |
No suspend was involved in either — the last suspend was hours before (PM: suspend exit at 20:01:13). The system journal has nothing at all in the surrounding minute in either case.
What is not the trigger
Both wedges end on an identical pair of lines, which looks like a smoking gun and is not one:
1password[1401]: Lock state changed: Locked
omarchy-shell[...]: WARN quickshell.dbus.properties: Error updating property
:1.41/StatusNotifierItem/org.kde.StatusNotifierItem:IconName
omarchy-shell[...]: WARN quickshell.dbus.properties: QDBusError(
"org.freedesktop.DBus.Error.Failed", "error occurred in Get")
:1.41 is 1Password, whose tray icon changes as it auto-locks. But this pair fires on all seven idle lock-timeouts across the two nights, including the five the shell survived. It is simply the last thing logged in every idle-lock cycle, so it is also the last thing logged before silence. Recording it here so nobody else spends time on it.
I could not find anything that distinguishes the two wedges from the five healthy locks. The trigger remains unidentified; the reproducer is only "leave the session idle-locked and wait", which hit twice in two nights here.
Relationship to #10108
Related but distinct. #10108 is IPC-dead (omarchy-shell is not responding), follows an S3 resume on a single-GPU NVIDIA desktop, leaves a stale background layer covering the desktop, and fails restart with An instance of this configuration is already running.
Here IPC stays alive and answers, there is no suspend, the visible result is Hyprland's lock failsafe rather than a stale wallpaper, and restart fails by refusing rather than aborting. The common thread is a quickshell that wedges without dying, so the supervision path never fires.
Suggested fix for the recovery half
Whatever causes the wedge, being unable to recover from it without a reboot seems worth fixing on its own. A --force flag on omarchy-restart-shell that skips the live-locker guard and goes straight to its existing relock path is enough — someone looking at the failsafe knows the lock screen is dead even when IPC insists otherwise. PR to follow.
System details
Omarchy 4.0.2-1, Quickshell 0.3.1-1, Hyprland 0.56.2-1, 1password 8.12.34-35, linux 7.1.9-arch1-2.
Laptop, hybrid GPU: Intel CometLake-H UHD (i915,
eDP-1) + NVIDIA GTX 1650 Mobile (nvidia-open-dkms). Single internal display, no external monitor. Wayland, uwsm session.What's wrong
Twice in one night,
quickshellwedged while the session was idle-locked. The process stayed alive and its IPC kept answering, but it stopped logging entirely and itsext-session-lockclient died — leaving Hyprland's crashed-lockscreen failsafe on screen until morning.The dangerous part is that IPC keeps serving the lock state the shell last reached, so the shell reports a healthy, secure lock long after its locker is gone:
omarchy-restart-shellthen refuses to recover it. Its guard reads exactly that status to decide whether a live locker is worth preserving:So the documented way out of the failsafe is blocked by the very state it exists to clear. The wedge is in the event loop, not the IPC thread, so a dead locker is indistinguishable from a healthy one over IPC. Short of patching a copy of the script, the only way back in is a reboot.
Occurrences
Both times: shell alive,
solitaryBlockedBycontainsLOCK, zero log lines afterwards.No suspend was involved in either — the last suspend was hours before (
PM: suspend exitat 20:01:13). The system journal has nothing at all in the surrounding minute in either case.What is not the trigger
Both wedges end on an identical pair of lines, which looks like a smoking gun and is not one:
:1.41is 1Password, whose tray icon changes as it auto-locks. But this pair fires on all seven idle lock-timeouts across the two nights, including the five the shell survived. It is simply the last thing logged in every idle-lock cycle, so it is also the last thing logged before silence. Recording it here so nobody else spends time on it.I could not find anything that distinguishes the two wedges from the five healthy locks. The trigger remains unidentified; the reproducer is only "leave the session idle-locked and wait", which hit twice in two nights here.
Relationship to #10108
Related but distinct. #10108 is IPC-dead (
omarchy-shell is not responding), follows an S3 resume on a single-GPU NVIDIA desktop, leaves a stale background layer covering the desktop, and fails restart withAn instance of this configuration is already running.Here IPC stays alive and answers, there is no suspend, the visible result is Hyprland's lock failsafe rather than a stale wallpaper, and restart fails by refusing rather than aborting. The common thread is a quickshell that wedges without dying, so the supervision path never fires.
Suggested fix for the recovery half
Whatever causes the wedge, being unable to recover from it without a reboot seems worth fixing on its own. A
--forceflag onomarchy-restart-shellthat skips the live-locker guard and goes straight to its existing relock path is enough — someone looking at the failsafe knows the lock screen is dead even when IPC insists otherwise. PR to follow.