https://bugs.kde.org/show_bug.cgi?id=527917
Thomas Braun <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Thomas Braun <[email protected]> --- I can confirm this on a different distribution (Arch-based EndeavourOS instead of Fedora) with the same 2 x 25 s timing signature, and I have evidence for a second plasmashell freeze vector that the "disable PIM Events" workaround does not cover. I've also checked how this relates to bug 524260 (RESOLVED FIXED) -- see point 6. 1) REPRODUCTION WITH THE PIM EVENTS PLUGIN DISABLED 2026-10-30, cold boot, 06:56 local time (CET): right after login the panel and desktop were unresponsive for ~50 s (pointer moved, clicks did nothing) -- the same symptom as described. The Digital Clock "PIM Events" plugin was verifiably disabled at that point (no pimevents entry in the plasma appletsrc config). akonadi_control journal: 06:56:07 "Akonadi server is now operational" 06:56:57 "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply'" exactly 50 s later -- i.e. the same two 25 s D-Bus timeouts resolving the cycle as in the report's timeline. During the 50 s window not a single Akonadi agent logged anything (no Google/IMAP sync activity); the first notification subscriptions (AgentBaseChangeRecorder) of the agent fleet appear in the very second the NoReply error fires -- matching the report's observation that kalendarac and ~15 other agents only get their AgentManager replies after ~50 s. 2) plasmashell IS AN AKONADI CLIENT EVEN WITHOUT PIM EVENTS: THE CONTACTS WIDGET With the PIM Events plugin disabled I still observe plasmashell acting as an Akonadi client: a) When Akonadi stops, the journal shows plasmashell holding connections to the Akonadi local sockets akonadiserver-cmd.socket and akonadiserver-ntf.socket ("connection closed by remote side"), exactly like kalendarac. b) lsof on the running plasmashell showed Akonadi libraries loaded: libKPim6AkonadiCore, libKPim6AkonadiContactCore, libKPim6AkonadiMime, libKPim6AkonadiWidgets, libakonadi_quick_plugin.so, akonadi_serializer_addressee.so c) The only Akonadi-related widget left in my panel was the (rarely used) Contacts widget. After removing it from the panel and restarting plasmashell, lsof shows plasmashell loading zero Akonadi libraries (re-verified after the next cold boot: still zero). So the Contacts panel widget is a second plasmashell-side Akonadi client, and the freeze reproduced here with the PIM Events plugin already disabled. The workaround from the report is therefore incomplete: as long as any Akonadi-using widget (PIM Events, Contacts) is in the panel, plasmashell can be dragged into the startup deadlock. This matches the fix commit for bug 524260 (f92a715c330759397bff7f669729b25bf264263a), which explicitly names "the Merkuro Contacts widget and the calendar events of the digital clock" as widgets that create Akonadi sessions on the plasmashell main thread. Which exact call blocks the GUI thread in the Contacts case is not pinned down on my side yet (D-Bus vs. Akonadi local socket) -- see point 5. 3) CENSUS FROM THE PERSISTENT JOURNAL The "NoReply ~50 s after 'operational'" signature appears intermittently at Akonadi startup on this machine since at least 2026-10-23: 2x on 10-23, 5x on 10-24, 1x each on 10-25, 10-26 and 10-30, plus a few during 10-29 (unrelated akonadiserver crash loop, bug 528012 -- different root cause). It never occurred mid-session, always within the first minute after Akonadi startup. In my sample the race hit roughly every other cold boot (the other boots reached operational state with all agents subscribed within ~2 s); the only warm restart in my dataset (D-Bus service activation) started cleanly as well. 4) ENVIRONMENT EndeavourOS (Arch, rolling), Plasma 6.8.1, Qt 6.12.0, akonadi 26.08.2, kdepim-runtime 26.08.2 (Google resource with calendar + contacts configured), MariaDB 13.0.2 backend, Wayland. On this system Akonadi is started by a systemd user service (akonadi_control.service) rather than kalendarac autostart -- the race appears independent of how Akonadi is started. 5) WHAT I CAN PROVIDE NEXT I have a script that, while a freeze is in progress, captures gdb backtraces of akonadi_control, akonadiserver and plasmashell plus the journal window (verified in a test run). Since removing the Contacts widget, plasmashell no longer loads any Akonadi code on my machine; to capture the blocked plasmashell GUI thread I would temporarily re-add an Akonadi widget to the panel first. If that would help triage, I can attach full backtraces of the next occurrence. (No deadlock has coincided with a boot since the removal, so "the panel stays responsive during the deadlock" is currently the structural prediction, not yet an observed data point.) 6) RELATION TO BUG 524260 (RESOLVED FIXED) All my observations were collected on akonadi 26.08.2, which predates the f92a715c fix (committed to master on 2026-10-14, not in the 26.08.x releases). Question for triage: does the async ServerManager::start() change also resolve the akonadi_control <-> akonadi_google_resource cycle described in this report, or is that cycle (resource calling AgentManager.agentTypes synchronously during init while akonadi_control calls accountId on the resource) a separate remaining deadlock? My journal data cannot distinguish the two server-side mechanisms; once the fix lands in a release I can re-test with a Contacts widget re-enabled and report whether the NoReply-at-startup signature disappears. The deadlock itself keeps occurring in the background regardless of the plasmashell-side workarounds, so the startup race remains observable here in the meantime. -- You are receiving this mail because: You are watching all bug changes.
