I’ve been chasing a reproducible bug where using Discover’s “Reboot after update” option doesn’t actually reboot the machine — applications close, but the Plasma session never logs out, and you’re left back at an empty desktop instead of a restart.
Bug report: https://bugs.kde.org/show_bug.cgi?id=525911
Symptom
- Install updates in Discover, choose “Reboot after update”
- Applications close as expected
- Instead of logging out/rebooting, you’re back at the desktop
- Journal shows:
plasma-shutdown: KWin failed to complete logout
Sometimes instead of failing fast, plasma-shutdown just hangs indefinitely (blocked, but still responsive to D-Bus) until something else nudges it.
What’s actually happening
After digging through the plasma-workspace, kwin, and discover sources and capturing the failure at the D-Bus wire level, this looks like a genuine race condition, not something environment-specific:
- Discover’s
UpdatesPage.qmlcan callorg.kde.Shutdown.logoutAndReboot
twice in quick succession (a QML state re-entry issue, seemingly tied to
how oftenPackageKit.Offlineproperties change right before the reboot
triggers). plasma-workspace’sShutdownclass has no guard against a second
concurrent logout request.- Both calls race down to KWin’s
closeWaylandWindows(). KWin correctly
rejects the second, overlapping call with"Operation already in progress"
— but that rejection currently kills the entireplasma-shutdownprocess,
taking the first, legitimate request down with it.
Full wire-level trace and analysis are in the bug comments, including a capture where two logoutAndReboot calls land ~400μs apart from the same Discover process, followed by KWin’s rejection and the process dying.
A friend with the same versions doesn’t see it
A friend running the exact same Fedora 44 / Plasma 6.7.5 / PackageKit setup (confirmed matching package versions) doesn’t hit this at all — he uses “Reboot after update” regularly and it just works for him. So whatever triggers the double D-Bus call isn’t purely a version thing; something about timing, update frequency, or environment tips it one way or the other. I haven’t been able to pin down what’s different yet, despite comparing repo lists, flatpak remotes, and PackageKit activity between our two machines.
What I’m trying to find out
- Is anyone else hitting this? Especially on distros other than Fedora,
or non-Fedora PackageKit backends — this looks like it should be reproducible
anywhere plasma-workspace + Discover + KWin are combined, not Fedora-specific. - If you do reproduce it, does it correlate with anything specific — lots of
installed COPRs/third-party repos, flatpak remotes, frequency of running
updates, etc.? - Honestly, I’m not entirely sure how best to proceed from here — I can
reproduce and trace it reliably on my own machine, but without a second
reliably-failing setup to compare against, I’m not sure whether the next
step is a code fix, more data-gathering, or something else. Open to
suggestions on the best way forward, including whether this is worth a
merge request as-is or needs more confirmation first.
Workaround
Until this is fixed, avoiding the “Reboot after update” combo box entirely sidesteps it: let Discover finish installing updates, then reboot manually (Start Menu → Restart, or systemctl reboot).
Environment: Fedora 44, Plasma/KWin 6.7.5, PackageKit 1.4.0 (dnf5 backend), PackageKit-Qt6 1.1.4.
Happy to share the raw D-Bus capture or dig further if it’s useful — just wanted to check whether this rings a bell for anyone else before assuming it’s specific to my setup.
.