Title: Discover’s “Reboot after update” fails to actually reboot — race condition, still trying to isolate the trigger
Body:
Posting here alongside an upstream KDE bug report and a discuss.kde.org thread, since this might still have a Fedora-specific angle even though I’ve ruled out a couple of theories already.
KDE bug: https://bugs.kde.org/show_bug.cgi?id=525911**KDE Discourse thread:** [link once posted]
Symptom
On the KDE Plasma spin, using Discover’s “Reboot after update” option:
- Updates install, applications close as expected
- The system never actually reboots — you’re back at an empty desktop
- Journal shows:
plasma-shutdown: KWin failed to complete logout
(sometimes it hangs for several minutes instead of failing immediately)
What I’ve found
Traced this to a genuine race condition: Discover’s update page can fire the D-Bus reboot request twice in quick succession, colliding with KWin’s own protection against duplicate logout requests. That collision currently kills the whole session-ending process instead of just ignoring the duplicate. Full writeup and a wire-level D-Bus capture are in the KDE bug.
What I’ve ruled out so far
- Package versions: a friend with the exact same
dnf5/libdnf5/
PackageKit/PackageKit-Qt6versions as me doesn’t reproduce this,
despite using “Reboot after update” regularly. So it’s not a broken
version of anything. - akmods/DKMS: none installed on my system at all (in-tree
amdgpu
only), so it’s not specific to out-of-tree kernel modules — at least not
on my end. - Number of open applications: closing everything before rebooting
doesn’t help; still fails. - VM/inhibitors: no virtual machines or unusual systemd inhibitors were
present during my documented failures.
What’s still open
Since it’s not a version difference, I suspect it’s either usage-pattern related (how often updates run, whether Discover’s window is open at the right moment) or something in my specific update/repo configuration that increases how often a particular D-Bus property-change timing window gets hit. My setup does have several third-party repos/COPRs and previously had a broken flatpak remote (since removed) generating constant errors — I can’t rule out that kind of background noise contributing, even if it’s not a clean single cause.
Genuinely unsure what to check next. If anyone recognizes this pattern or has ideas on what else might differ between two otherwise-identical systems where one reliably reproduces a race condition and the other doesn’t, I’d appreciate the input.
Workaround
Skip the “Reboot after update” combo box — let Discover finish, then reboot manually (Start Menu → Restart, or systemctl reboot).
Environment: Fedora 44 (KDE Plasma Desktop Edition), Plasma/KWin 6.7.5, PackageKit 1.4.0, dnf5/libdnf5 5.4.5.0-1.CPU: AMD Ryzen 7 7800X3D | GPU: AMD Radeon RX 9070 XT + Raphael iGPU (amdgpu, no akmods) | MSI B650 Tomahawk WIFI, BIOS 1.L0
