https://bugs.kde.org/show_bug.cgi?id=525911
--- Comment #2 from [email protected] --- Following up on my earlier comments: I instrumented the session with a scoped busctl --user monitor capture (matching org.kde.Shutdown, org.kde.KWin.Session, org.kde.KSMServerInterface, org.kde.LogoutPrompt, plus all D-Bus errors) and caught the failure live this morning. This is a full wire-level confirmation of the race I described earlier, not a hypothesis anymore. Trace (timestamps UTC, from the same failure — journal shows the matching KWin failed to complete logout at the same second): ``` 07:01:50.872 :1.171 → org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndReboot [call #1] 07:01:50.927 plasma-shutdown → org.kde.ksmserver /KSMServer closeSession [flow #1] 07:01:50.928 ksmserver → org.kde.KWin /Session setState(1) [Saving] 07:01:51.259 :1.171 → org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndReboot [call #2, +386ms, SAME sender] 07:01:51.259 plasma-shutdown → org.kde.ksmserver /KSMServer closeSession [flow #2, duplicate] 07:01:53.135 ksmserver → org.kde.KWin /Session setState(2) [Quitting] 07:01:53.137 plasma-shutdown → org.kde.KWin /Session closeWaylandWindows [flow #1's call] 07:01:53.137 plasma-shutdown → org.kde.KWin /Session closeWaylandWindows [flow #2's call, +387ms] 07:01:53.137 KWin → error org.freedesktop.DBus.Error.Failed: "Operation already in progress" (reply to flow #2's closeWaylandWindows call) 07:01:53.138 plasma-shutdown → org.kde.ksmserver /KSMServer resetLogout ``` :1.171 traces to plasma-discover (PID 609089, running 08:55:07–09:01:53, systemd scope closing at the exact same second as the failure). So this is Discover's own DiscoverObject::rebootNow() calling org.kde.Shutdown.logoutAndReboot twice, 386ms apart, from the same process — consistent with UpdatesPage.qml's onStateChanged handler re-entering the "reboot" state (no guard against firing more than once; see my first comment on this bug for the PreparedUpgrade property-invalidation churn that would drive that). Both calls raced through the same running plasma-shutdown process, since Shutdown::startLogout() (plasma-workspace/startkde/plasma-shutdown/shutdown.cpp) has no re-entrancy guard — nothing stops two concurrent logoutAndReboot() invocations. Both flows eventually reach Shutdown::ksmServerComplete() and call KWin's closeWaylandWindows(). KWin's own single-flight guard (m_closingWindowsGuard in kwin/src/sm.cpp, SessionManager::closeWaylandWindows()) correctly rejects the second call with exactly "Operation already in progress" — that string is a direct match to the sendErrorReply(QDBusError::Failed, u"Operation already in progress"_s) in that function. The problem is what happens next: that rejection lands in flow #2's QDBusPendingCallWatcher, and Shutdown::ksmServerComplete()'s error branch does: ```cpp qCWarning(PLASMA_SESSION) << "KWin failed to complete logout"; ksmserverIface.resetLogout(); logoutCancelled(); // → qApp->quit() ``` Since both flows live in the same process, qApp->quit() tears down the entire plasma-shutdown process — including flow #1's still-pending, legitimate closeWaylandWindows() call (sent one message earlier, Cookie=16 vs Cookie=20), which had a real chance of completing successfully on its own. The session never ends; the user is left at the desktop with all applications already closed. -- You are receiving this mail because: You are watching all bug changes.
