The way PIM (Personal Information Management) works under KDE, is that it has a server called the ‘Akonadi Server’, which provides back-ends that allow the desktop system to synchronize with other applications.
For example, I use it to synchronize my desktop calendar with Google Calendar.
In order for Akonadi to work, it creates a MySQL database-engine instance, in the personal folders of one user – i.e. in user-space. This is remarkable, because ordinarily, the MySQL server is supposed to run as a system process, which means that any user needs a database user-name and password, even to connect to the MySQL server on his own machine. But Akonadi has sidestepped this need, by allowing a separate instance of the server-process to run entirely in his user-name.
What this used to mean for package-dependencies, is that a computer was allowed only to have ‘
mysql-core‘ and ‘
mysql-client‘ installed, without having to have ‘
mysql-server‘ installed, as the binaries can be pulled in without the ‘
mysql-server‘ package, the latter of which merely used to enable the (system-wide) daemon.
Well, the latest MySQL update ran perfectly on my server-box ‘Phoenix’, because this machine already had the system-wide server process installed and operational.
But on my laptop named ‘Klystron’, Akonadi would not start, since the latest MySQL update. In obscure, buried error messages, it would complain that the directory ‘
/var/lib/mysql-files‘ could not be accessed.
BTW, MySQL does not run as
root, but rather under user-name ‘
After an hour of work on my laptop I discovered that the newer MySQL versions will not run the server-process at all – not even the way Akonadi configures it – unless we also have the package ‘
mysql-server‘ installed. Installing this package finally allowed Akonadi to start again. Doing so will firstly define the user-name ‘
mysql‘, and secondly create the needed directory, belonging to that user-name.
It might help some other people to know this, before they wipe their Akonadi database directory. My favorite way to fix Akonadi errors was just to wipe it, but this time that solution would not work.
Also, once I had created the MySQL server as a system service, I had to assign an initial root password for it. But I never had to enter that system password, in order for Akonadi to work again. If the system DB was being used, that would not be possible, because any user process would first need a user DB, and a user DB password, which would require that the root credential be entered to accomplish.
(Edit 11/15/2016 : ) Given the latest update to Akonadi, by KDE developers, this issue may have been fixed.