Akonadi Server Update Successful Today

My Linux computers have PIM Software installed (…Personal Information Management), which is implemented with the KDE Desktop Manager, through a service which runs in user-space, called ‘Akonadi’. This service allows personal information to be synchronized across several platforms, including Google, Given the wishes of the user.

The most common way in which Akonadi is installed, is with its MySQL back-end for storing information locally, and doing so enables the software developers to run an instance of the MySQL database server, not as a system service, but by default as a localized instance, that accesses the folders of one user and only requires the user-name of one user.

According to this earlier posting, an update to the MySQL software itself, broke this way in which Akonadi works – probably because Debian developers did not coordinate that update with KDE developers. According to what I had written there, the system-wide package ‘mysql-server‘ needed to be installed, that also launches the system-wide daemon, before the form of it localized for use with Akonadi would run again. This upset the way I had installed my Laptop ‘Klystron’, where I had previously not thought it necessary to install the system-wide server, to enjoy the use of Akonadi.

Just this evening, KDE developers and Debian / Jessie package maintainers pushed through an update to several Akonadi-related packages, which I installed using my package manager. When we do this, user processes such as Akonadi are not restarted automatically, since in doing that, the package-manager would also break the current session.

And so what I needed to do in order to apply the update, was just to log out of my current, graphical desktop session, and log back in again.

But according to this earlier posting, there has been a history as well, of such attempted log-outs hanging, leaving just the mouse-pointer showing, and leading to no further, apparent progress in actually logging out. So, as of October 21, I had enabled the <Ctrl>+<Alt>+Backspace key-combination on all the desktop sessions, which needs to be arranged before the desktop session is started, so that I would effectively be able just ‘to blow away the current session’, in case a log-out hangs again.

This time around, while I was performing the log-out, my procedure did hang again, leaving me waiting for a few minutes, taking from 19h55 until 20h05 in total. But I did use the <Ctrl>+<Alt>+Backspace key-combination, to hasten the restart of the X-server, which meant that I was not forced to reboot the computer.

This turned the update into a Success, because system services such as the Apache Web-server and ‘memcached‘, and the system-wide MySQL database server, did not need to be restarted. And as a result, there was no disruption in any form to the blog or to my site.


Now, Because I have the system-providing mysql-server package installed already both on my Laptop, as well as on this server-box ‘Phoenix’, I cannot tell whether this update did in fact fix that issue. Also, I cannot be sure that the update was meant to fix that issue. All I know, is that nothing is broken as it stands, and no services were disrupted.



An Added Note about Akonadi

In This Earlier Posting, I had written about a specific problem, which can happen, because the Linux / KDE PIM software (Personal Information Manager) uses Akonadi, and because Akonadi (still) runs a MySQL server-process, in the user-name of the user, within the personal folders of this user.

I also wrote that I use this, to sync my calendar, on my Linux machines, with my Google Calendar, and for nothing else.

I suppose that one fear which people might get from reading this, is that their Google Tokens might be stored in the Akonadi server. This is in fact untrue.

When Akonadi starts – which is when a user logs in to a new session – Akonadi actually retrieves any credentials it is going to use, from an additional KDE service called “Kwallet”. Kwallet is a miniscule store of secretive information, such as log-ins and tokens, which are protected by a password, which is used to encrypt all the contents of this wallet.

Hence, when I log in a user-session, I am also greeted by a password prompt from Kwallet, without which Akonadi could not retrieve its tokens. Certain other KDE applications also use this wallet feature.

So it is not actually the case, that KDE somehow muffs up the security, and stores such credentials anywhere in plain-text.

If we forget our password to Kwallet, then what we must ultimately do is delete our Kwallet, which also deletes any store of the secretive information we may have had. Doing so also does not recover the previous version of such information. That would need to be recreated from scratch.

Also, these types of issues make me happy, not to be using ‘KMail’ as my email client. KMail would store my email folders on Akonadi as well. And, seeing as I may frequently need to wipe Akonadi, due to certain reliability / configuration quirks, I would be losing all my email folders each time as well.

The email client I use under Linux is called ‘Icedove’, and is the unbranded version of ‘Thunderbird’. It has all the features which Thunderbird would have, but runs perfectly under Linux. It does not depend on Akonadi, nor on anything else KDE specifically.



New MySQL Update Breaks Akonadi, Unless ‘mysql-server’ Is Installed.

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 ‘mysql‘.

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.