https://bugs.kde.org/show_bug.cgi?id=525919
--- Comment #6 from [email protected] --- (In reply to Norbert Harrer from comment #4) > 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. Thanks, this matches what I see, and it explains my results better than my hypothesis in comment #0 did. My control tests fit the double-request explanation. Every launcher-initiated restart succeeded, including one with Discover open and idle, which would send a single logoutAndReboot. Only the restarts that Discover triggered after an update failed (2 of 2 on Sep 18). My journal also supports your regression range. plasma-discover 6.7.5-1.fc44 was installed here on 2026-09-11 19:17 EDT. There are no "KWin failed to complete logout" entries between Feb 6 and Sep 13. After that there are six, between Sep 13 and Sep 18 (13, 14, 16 x2, 18 x2). There are four older entries from Jan/Feb that I haven't classified yet. They may be unrelated manual logouts. -- You are receiving this mail because: You are watching all bug changes.
