## 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.

Yay!

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.

Dirk

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.

Dirk

## Routine Desktop Session Restart

According to This Earlier Posting, the ‘unattended-upgrades‘ package updated a whole slew of MySQL packages this morning, that of course form the most important database engine on this machine (‘Phoenix’). As an automated part of the process, the update restarted the MySQL Server process, which runs as a system service.

However, the way KDE works, it has an Akonadi Server for ‘PIM’ (Personal Information Management), which runs its own, local MySQL database engine, as part of the user session, which is of course not restarted automatically, because to do so would also interfere strongly with a running session.

And yet, this latter process can also be brought up-to-date, by just logging out the (graphical) desktop session, and logging back in again. Doing so should not affect any of the system processes, which either run as ‘root‘, or which run as a vestigial, system user-name. Likewise, doing so should not affect the Web-server.

Hence, to bring my session up-to-speed, I performed this logout / login successfully and without ado, which actually took from 15h15 until 15h25.

Yet, there was An Earlier Situation, in which an attempt to do the same thing went wrong.

## Routine MySQL Update Successful Today

I use a system for updating my packages, which is named ‘unattended-upgrades’, and which I have blogged about before Here.

This morning, that system updated my MySQL server, which is also important to this blog, because these blog entries are in fact stored in a MySQL database. The way my blog generally works, each HTTP request causes a PHP script to be executed independently on the Apache server, and the PHP extensions I have installed, include a MySQL client. This part of the PHP scripts fetches the blog content, while other parts of the scripts format it as HTML, according to the Theme which I have chosen to install some time ago.

The individual blog entries do not actually form separate files or folders on my Web-site.

Also, it is an explicit WordPress Plug-In, which tries to retrieve the already-formed HTML from my server cache, If the HTML being requested has been cached. That Plug-In is named ‘Memcached Is Your Friend‘.

The fact that my blog still displays properly, indicates that the MySQL database is operating normally. After the upgrade, the scripts also restarted this server briefly. And, the fact that this server has been restarted, does not affect the cache, nor the speed of the blog, because the ‘memcached’ daemon is a separate process which did not receive any update or restart.

Dirk