https://bugs.kde.org/show_bug.cgi?id=525919
Norbert Harrer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |[email protected] Status|REPORTED |CONFIRMED --- Comment #4 from Norbert Harrer <[email protected]> --- Confirming this on Fedora 44, Plasma 6.7.5, plasma-discover 6.7.5-1.fc44, with offline updates enabled (Fedora ships UseOfflineUpdates=true in /etc/xdg/discoverrc, upstream default is false). I captured the session bus during a failing run. The proximate cause is that Discover sends logoutAndReboot twice, and the second request makes plasma-shutdown cancel the logout the first one had already started. Disclosure: the bus capture and journal analysis, and this write-up, were done with AI assistance. Everything here is from my own system and can be checked against the attached capture; the parts I could not verify are marked as such. CAPTURE busctl --user monitor org.kde.KWin org.kde.ksmserver org.kde.Shutdown (:1.196 = plasma-discover, :1.217 = plasma-shutdown, :1.31 = kwin; times UTC) 14:24:28.568533 Cookie=127 :1.196 -> org.kde.Shutdown /Shutdown logoutAndReboot 14:24:28.945658 Cookie=128 :1.196 -> org.kde.Shutdown /Shutdown logoutAndReboot 14:24:32.496684 Cookie=16 :1.217 -> org.kde.KWin /Session closeWaylandWindows 14:24:32.497246 Cookie=20 :1.217 -> org.kde.KWin /Session closeWaylandWindows 14:24:32.497457 ReplyCookie=20 :1.31 -> :1.217 org.freedesktop.DBus.Error.Failed "Operation already in progress" 14:24:32.498198 Cookie=24 :1.217 -> org.kde.ksmserver /KSMServer resetLogout journal, same moment: plasma-shutdown[18394]: KWin failed to complete logout The two logoutAndReboot calls are 377 ms apart and carry consecutive serials (127, 128) on Discover's session-bus connection, i.e. Discover issued no other session-bus method call between them. WHAT THEN HAPPENS In plasma-workspace/startkde/plasma-shutdown/shutdown.cpp (v6.7.5): - each logoutAndReboot runs startLogout() -> ksmserver closeSession() -> ksmServerComplete() - ksmServerComplete() calls KWin closeWaylandWindows(); the second call gets Error.Failed - the reply is not valid, so the code logs "KWin failed to complete logout", then calls ksmserverIface.resetLogout() and logoutCancelled() (shutdown.cpp:105-108) - logoutCancelled() only quits plasma-shutdown; SessionBackend::reboot(), reached from logoutComplete(), is never called This matches the user-visible symptom exactly: the open windows are gone (KWin closed them for the first request), background/tray apps survive, the session stays up, and nothing is reported in the UI. Regarding the hypothesis in comment #0 that Discover blocks the reboot with new get-updates/resolve transactions: those transactions do occur here too, but they are on the system bus and are not what cancels the logout. They may still be the root cause one level up, see below. WHY TWICE (NOT YET PROVEN) discover/qml/UpdatesPage.qml calls app.rebootNow() from onStateChanged whenever state becomes "reboot" (line ~630 in v6.7.5 and in master). Nothing makes that idempotent, and DiscoverObject::rebootNow() has no guard either. If the page leaves "reboot" and re-enters it, the call is repeated. The state binding depends on isProgressing / isFetching / hasUpdates / needsReboot across all loaded backends, so a late needsReboot or fetching change from any backend, arriving after PackageKit has already armed the offline update, would do it. This machine runs three backends: PackageKit, Flatpak and fwupd. I have not instrumented which one causes the second transition. REGRESSION RANGE On this machine the persistent journal reaches back to 2026-08-26 and contains no Discover-triggered occurrence before plasma-discover 6.7.5-1.fc44 was installed on 2026-09-11 01:41. The first is 2026-09-11 08:23, the first update run after that upgrade, and it then recurs on 09-13, 09-17 (twice) and four times on 09-19. In the two weeks before that, on 6.7.4, roughly nine offline updates completed using the same "Restart" option with no failure, and the option had been used routinely and worked. (One occurrence of the same message on 2026-09-04 14:25 was a manual restart via the logout prompt, not Discover.) Two commits in v6.7.4..v6.7.5 touch needsReboot and are candidates: d2be2f00c fwupd: Regression, do not mistake an update for needsReboot (2026-08-31) 884079c43 Fix updates being stuck when fwupd is unavailable (2026-09-04) Older but also relevant: c5807ca00 (2026-04-10, first released in v6.6.90) moved the reboot trigger out of a StateChangeScript inside State { name: "reboot" } into the onStateChanged handler. Neither discover master (c9ca2d0f5) nor plasma-workspace master (1c0281b889) has a guard against a repeated request, on either side. POSSIBLE FIXES - Discover: make rebootNow()/shutdownNow() fire at most once per update run - plasma-shutdown: ignore a logout request while one is already in progress, rather than cancelling the one that is running Either alone would fix the symptom; the second also protects against any other caller doing this. WORKAROUND After the update finishes, reboot manually. The offline update stays armed, so it installs on that boot. The attached capture contains the messages of this logout chain, including both closeSession calls, which show startLogout() running twice. I still have the full unfiltered capture of that run and can provide it on request. -- You are receiving this mail because: You are watching all bug changes.
