quattro
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
0900855a28 |
Stop hot-reloading the shell when a package upgrade rewrites it (#6751)
Quickshell watches the QML it loaded and reloads on change, so pacman replacing /usr/share/omarchy/shell mid-transaction makes the running shell reload against a half-written tree. That reload fails, and a failure that reaches the config load is not harmless: it raises the reload popup, which is a second engine generation. EngineGeneration::currentGeneration() returns null unless exactly one exists, so the IPC kill that omarchy-update sends moments later takes the QCoreApplication::exit(0) branch instead of the generation's own quit, and Quickshell tears the QML graph down after deleting the QGuiApplication. The first GUI resource touched on the way out aborts: FATAL: QPixmap: Must construct a QGuiApplication before a QPixmap The user gets the crash dialog after an update and a coredump per occurrence. Reported in #6748 with 3 crashes across 10 updates, always following a failed reload. Fixing this in omarchy-update — stopping the shell around the pacman step — would cover one caller and cost the polkit agent and the notification server for the length of the transaction, which the migrations that run next still notify through. It would also have to carry omarchy-restart-shell's refusal to restart a locked session, or reintroduce the hazard that refusal exists for. And omarchy-update is not the only thing that rewrites the tree. The pacman guard turns away a bare pacman -Syu, but nothing turns away a targeted pacman -S omarchy, a pacman -U of a locally built package, the documented OMARCHY_ALLOW_DIRECT_PACMAN bypass, omarchy-dev-pkg-test, or a checkout in a dev-linked tree. Turn the watcher off instead. Omarchy has never reloaded through it: omarchy-restart-shell is what picks up QML changes, and config and plugin changes go through the shell's own IPC. Third-party plugin hot reload is PluginRegistry's own inotifywait and FileView watches its own files, neither of which this touches — QuickshellSettings::watchFiles() gates the config scanner and nothing else. The popup goes off with it, because QML can still ask for a reload directly and leave the same extra generation behind. Environment reaches Quickshell only at launch, so the update that delivers this still runs under a watching shell. It takes effect from the next one. Verified against an isolated instance: breaking a config in place and then sending the IPC kill reproduces the FATAL, and it stops with either variable set. QS_DISABLE_FILE_WATCHER also keeps the failed reload from happening at all. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
1e7bb66556 |
Recover a session lock stranded by a dead shell (#6692)
* Detect a compositor session lock through one helper omarchy-restart-shell decided whether the session was locked by looking for "LOCK" anywhere in the hyprctl monitors payload. That works, but not for the reason the code reads like: Hyprland reports no lock state of its own, and the string comes from solitaryBlockedBy, the list of reasons a monitor cannot hand a client the whole screen. An active ext-session-lock is one of those reasons. A substring match over the whole payload also answers yes to a workspace or a monitor description that merely spells LOCK, and locking a desktop nobody asked to lock is the worst way to be wrong. Match the reason list itself, and put it behind a helper now that a second caller needs the same answer. That second caller needs a third answer too, because the reason list is not always readable. Hyprland stops at the first reason on a monitor with no workspace yet — one just coming back — and returns before it ever looks at the lock, so a missing LOCK there means nothing was asked rather than nothing was found. Neither that nor an unreachable compositor is an unlocked session, and locks strand precisely while outputs are coming and going, so both exit 2. Callers that only branch on success are unaffected. The test fixture claimed the string came from a workspace name, so it was encoding the wrong model of the compositor. It now returns what Hyprland actually returns. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Retake a session lock stranded by a dead shell ext-session-lock keeps the session locked when its client goes away — that is the point of the protocol, so a crashing lock screen cannot expose the desktop. The cost is that a shell which dies while locked leaves the compositor locked with nothing left to authenticate against: Hyprland's failsafe, which takes a TTY or another machine to clear. Nothing carried the lock across a restart. Quickshell relaunches itself after a crash and omarchy-restart-shell can be run by hand, but both bring back a shell holding no lock, so the failsafe stayed up. A fresh shell never holds a lock, so a session already locked as the lock service starts can only be that orphan: take it back and let the user type their way out. Asking once is not enough. These deaths happen while outputs are going away, and the replacement shell comes up inside that same window, where there is nothing to read a lock off. So the question is asked until the answer means something: on a short timer while the session settles, and again when a screen comes back, since a display asleep for hours outlasts any timer worth running and returns through a state the compositor cannot answer for either. Once an answer does arrive the search ends, so the timer stops and later screen changes cost nothing. Three ways this could lock a desktop nobody asked to lock, all closed. A lock this shell took itself is not an orphan, including one taken while the question was in flight — omarchy-restart-shell re-locks a fresh shell, and the answer cannot tell whose lock it found. Recovery runs once and clears the flag, so nothing lingers to fire after an unlock. And PAM landing late reopens the question rather than answering it: clearing the failsafe from a TTY is the documented way out, so a yes from before there was anything to do about it may be stale by the time it can be acted on. The check has to live here rather than in the launcher. Quickshell's crash handler re-execs in place, keeping the same pid, so a supervising process never sees the restarts that recovery matters most for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Relaunch the shell when it dies without a signal Quickshell restarts itself after a crash, but only from its signal handlers: SIGSEGV, SIGABRT, SIGFPE, SIGILL, SIGBUS, SIGTRAP. Qt does not always leave that way. When the Wayland connection fails, QWaylandDisplay::checkWaylandError calls _exit() directly, which raises no signal at all — so the crash handler never runs, no report lands in ~/.cache/quickshell/crashes, and the desktop is left with no bar and no explanation. That is how #6684 ends: the lock path meets a screen with no valid Wayland output, declines to create a lock surface for it, and the connection dies with EINVAL. Supervise the launcher so those deaths come back. A clean exit is deliberate — omarchy-restart-shell stops the shell over IPC and starts its own replacement — and a signal to the supervisor means the session is going away, so neither relaunches. Neither does a shell that outlived its compositor, though that takes more than one unanswered query to conclude: the shell dies while outputs are being reconfigured, which is also when a busy compositor can miss one without being gone. A shell that cannot stay up gives up after five tries in a minute rather than spinning. Signals need care now that a launcher stands between the session and the shell. Bash defers a trap until a foreground command returns, so the shell runs as a job and the supervisor waits on it. Stopping the launcher used to stop the shell with it, back when this script exec'd Quickshell, so the signal is passed on rather than leaving a desktop nobody is watching. One arriving during the backoff sleep only reaches the trap afterwards, so the flag is read again at the top of the loop: a shutdown racing a crash would otherwise get one more Quickshell on its way out. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |