Preamble, I've done some research and as usual we have a cornucopia of similar questions but not exactly covering the described title:

My scenario:

  • fresh Tuxedo laptop with Debian GNU/Linux bookworm (current stable, 2023) with KDE
    • (this problem may happen in other Debian/Ubuntu distros with KDE)
  • Run sudo apt install mariadb-server

What happens:

MariaDB server cannot be installed and does not start correctly because something else is running:

Preparing to unpack .../04-mariadb-server_1%3a10.11.4-1~deb12u1_amd64.deb...
Failed to stop mariadb.service: Unit mariadb.service not loaded.
invoke-rc.d: initscript mariadb, action "stop" failed.
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
Attempt to stop MariaDB/MySQL server returned exitcode 5
There is a MariaDB/MySQL server running, but we failed in our attempts to stop it.
Stop it yourself and try again!

The apt cache show mariadb-server says that my package is 1:10.11.4-1~deb12u1.

I've inspected a bit my situation, and indeed I have not MariaDB already installed, and indeed it's not running as root. But, I have something called "akonadi" that is running as my dedicated low-privileged desktop username and it seems it's running its dedicated MariaDB for some reasons.

I've seen in fact this unknown line in my process list, probably part of a desktop dependency:


I think that my KDE comes as default with this package called akonadi-backend-mysql that runs a MariaDB as default and this breaks the installation of mariadb-server.

Does it make sense? Why? How to fix this and install mariadb-server?

1 Answer 1


Yes, it seems that in Debian bookworm KDE (and maybe other distributions like Ubuntu KDE etc.) there is this executable called akonadi that runs as default with the package akonadi-backend-mysql that requires its own MariaDB that - in theory - is completely separated from mariadb-server but in practice it's not.

This bug is officially tracked by Debian but it's unclear if, at the time of writing (2023-12-18), it will receive a fix in bookworm.



already once fixed in https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/38198d0b9e1c7821ddd074e308b25034bdcdce5b but then Debian release managers considered it too risky to include in Debian 13 "Bookworm" and thus it got reverted, and pending to be re-applied in https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/48

The package mariadb-server itself should not interrupt the installation if your system is just running the standard Akonadi with its dedicated MariaDB. But indeed you may have no time to troubleshoot or hot-patch such critical package on yourself.


A simple and clean solution is to:

  1. Stop Akonadi
  2. Migrate Akonadi from MariaDB to SQLite
  3. Start Akonadi again
  4. Retry

Interestingly, the migration of Akonadi from MariaDB to SQLite is well covered by the official documentation of KDE (section "How do I switch from MySQL/PostgreSQL to SQLite?"). Read this documentation if you want further information about Akonadi itself, what it does, what kind of data it stores and why, etc.


In short, as solution, from your desktop user:

akonadictl stop
rm -Rf $XDG_CONFIG_HOME/akonadi
rm -Rf $XDG_DATA_HOME/akonadi
rm -Rf $XDG_CONFIG_HOME/akonadi*
rm -Rf $XDG_DATA_HOME/akonadi*

Then edit the file $HOME/.config/akonadi/akonadiserverrc. From:




Then start Akonadi again with akonadictl start and try again your MariaDB installation.

It worked for me exactly in this way in a laptop with Debian GNU/Linux bookworm KDE.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .