The problem occurs when syncing executes the source initialization in a background thread. Akonadi::ServerManager::isRunning() then returns false despite Akonadi running. This initialization in a thread was introduced to avoid timeout issues with slow sources: * engine: prevent timeouts in HTTP server mode HTTP SyncML clients give up after a certain timeout (SyncEvolution after RetryDuration = 5 minutes by default, Nokia e51 after 15 minutes) when the server fails to respond. This can happen with SyncEvolution as server when it uses a slow storage with many items, for example via WebDAV. In the case of slow session startup, multithreading is now used to run the storage initializing in parallel to sending regular "keep-alive" SyncML replies to the client. By default, these replies are sent every 2 minutes. This can be configured with another extensions of the SyncMLVersion property: SyncMLVersion = REQUESTMAXTIME=5m Other modes do not use multithreading by default, but it can be enabled by setting REQUESTMAXTIME explicitly. It can be disabled by setting the time to zero. The new feature depends on a libsynthesis with multithreading enabled and glib >= 2.32.0, which is necessary to make SyncEvolution itself thread-safe. With an older glib, multithreading is disabled, but can be enabled as a stop-gap measure by setting REQUESTMAXTIME explicitly. I checked, setting SyncMLVersion=REQUESTMAXTIME=0m in the sync config involving the Akonadi sources works around the problem for me. I'll check with the KDE devs to find out why Akonadi::ServerManager::isRunning() fails in this scenario.