https://bugs.kde.org/show_bug.cgi?id=527917
Bug ID: 527917
Summary: Startup D-Bus deadlock between akonadi_control and
akonadi_google_resource (accountId ↔ agentTypes)
freezes plasmashell for ~50 s at login
Classification: Frameworks and Libraries
Product: Akonadi
Version First 6.8.1
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Google Resource
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Target Milestone: ---
SUMMARY
Sporadically (6 of 17 logins) the Plasma desktop is unresponsive for ~50 s
right after login: the pointer moves, but clicks on panel/desktop do nothing. I
recorded the session bus with `dbus-monitor --session --profile` during login
and found the cause: a synchronous D-Bus call cycle between akonadi_control and
akonadi_google_resource during Akonadi startup. It only resolves after two 25-s
D-Bus timeouts. plasmashell (Digital Clock with the "pimevents" calendar
plugin) makes a synchronous AgentManager call to akonadi_control in that window
and blocks its GUI thread for the full duration.
TIMELINE (2026-10-28, from dbus-monitor --profile, headers only)
07:54:27.2865 akonadi_control -> akonadi_google_resource_0 /Account
org.freedesktop.Akonadi.Agent.Account.accountId (sync, waits)
07:54:27.2879 google_resource -> org.kde.kwalletd6 networkWallet (answered
immediately)
07:54:27.2880 google_resource -> org.freedesktop.Akonadi.Control
/AgentManager agentTypes (sync, waits)
=> both processes wait for each other
07:54:27.83 plasmashell -> Akonadi.Control /AgentManager agentTypes
-> reply after 49.94 s
07:54:27.28 kalendarac, akonadi_unifiedmailbox_agent and ~15 other agents ->
AgentManager agentName/agentComment/... -> replies after 50.49 s
07:54:52.77 accountId times out (25 s), akonadi_control immediately calls
accountId on the resource again -> second 25-s timeout
07:55:17.77 akonadi_control logs: "D-Bus communication error
'org.freedesktop.DBus.Error.NoReply'"; everything continues normally
On an earlier occurrence (2026-10-26) the identical pattern was recorded; in
that case kwalletd6 was being D-Bus-activated by the resource's networkWallet
call (~130 ms), which widened the race window. Pre-starting kwalletd6 before
Akonadi did NOT fix it: today kwalletd6 was already running and answered in < 1
ms, yet the cycle still formed, because akonadi_control's accountId call
arrived ~1.5 ms before the resource's own agentTypes call. So the root cause is
the synchronous call cycle itself, not KWallet.
STEPS TO REPRODUCE
1. Have a Google resource configured (calendar/contacts) and the Digital Clock
widget with "PIM Events" calendar plugin enabled.
2. Log in to Plasma (Wayland). Akonadi is started via kalendarac autostart.
3. Repeat; the race hits roughly every third login.
OBSERVED RESULT
akonadi_control and akonadi_google_resource deadlock for 2 × 25 s; plasmashell
(and every other Akonadi client asking AgentManager) is blocked meanwhile ->
Plasma freezes ~50 s.
EXPECTED RESULT
No synchronous call cycle: akonadi_control should not issue blocking calls
(accountId/name) to an agent from inside its main loop while that agent may
call back into AgentManager during its startup, or the resource should not call
AgentManager synchronously during init. Additionally, plasmashell's pimevents
plugin should not call AgentManager synchronously on the GUI thread.
WORKAROUND
Disable the "PIM Events" plugin in the Digital Clock settings. The deadlock
still happens in the background, but Plasma no longer freezes.
SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 44
Kernel: 7.2.11-200.fc44.x86_64
Graphics Platform: Wayland
KDE Plasma Version: 6.7.5
KDE Frameworks Version: 6.31.0
Qt Version: 6.11.2
Akonadi / kdepim-runtime: 26.08.1 (KDE Gear; Akonadi 6.8.1)
ADDITIONAL INFORMATION
Likely the same root cause as bug 525435 ("Desktop frozen for about 90 seconds
after reboot") – a commenter there noticed that Akonadi apps don't start until
the freeze ends.
--
You are receiving this mail because:
You are watching all bug changes.
