Botched KDE-PIM Update, Downtime

If your Linux system uses ‘KDE’, then it is KDE which manages our desktop environment. KDE stands for “K Desktop Environment”. Further, there is a subsystem of KDE, which is known as its ‘PIM’ system, which stands for “Personal Information Management”. The KDE PIM system relies on a user-space server, called “Akonadi”.

Just today, the package manager pushed through an Update to the KDE-PIM system, including a major reworking of Akonadi.

This number of updated packages, will often require a general reboot of the system. But because this update only affected the Desktop Session, it should have been possible only to do a log-out, and then to log back in. No part of the Apache Web-server depends on KDE, so that the Apache server should have been able to keep running, and to keep serving out my Web-site.

However, due to the way in which this update was administered, such a log-out was not possible. The desktop session just hanged, when an attempt was made to log it out. A complete reboot was nevertheless required. Therefore, even though all the new components seem installed correctly, this update was botched.

As a result, my Site and my Blog were inaccessible from approximately 20h05 until 20h20.

Simultaneously, my Linux laptop named ‘Klystron’ received a Kernel-Update to version 4.4.0-46, which apparently succeeded. However, it too received the KDE-PIM-Akonadi update, which means that the task of simply rebooting it also ran into difficulty. In this case, the message appeared, “Stop Job Running for User Dirk”, which timed out after 90 seconds.

I apologize for any inconvenience.

Oh Yes. And the blog will seem slightly sluggish for several hours or even a day, because rebooting, always clears the server cache.

I have given some thought, to how I might just avoid such problems in the future. What seemed to happen on ‘Phoenix’, was that certain user-processes – presumably Akonadi-related – were unable to exit, so that the log-out attempt kept waiting for them to do so. Only after doing a <Ctrl>+ <Alt>+F1, and then an ‘su; init 6‘ did I override that.

These last few lines of my ‘/var/log/Xorg.0.log.old‘ state:

 


[166957.727] (II) evdev: AT Translated Set 2 keyboard: Close
[166958.722] (II) UnloadModule: "evdev"
[166958.722] (II) evdev: HID 062a:0000: Close
[166958.723] (II) UnloadModule: "evdev"
[166958.723] (II) evdev: Power Button: Close
[166958.723] (II) UnloadModule: "evdev"
[166958.723] (II) evdev: Power Button: Close
[166958.723] (II) UnloadModule: "evdev"
[166961.884] (EE) Server terminated successfully (0). Closing log file.
root@Phoenix:/var/log# 

 

What this suggests, is that the command never actually reached the X-server, to shut down, until I gave the command ‘init 6‘, from VT1.

My past assumption was, that to leave the <Ctrl>+<Alt>+Backspace disabled, would be ‘more secure’. But since the ability to keep Apache running seems more important these days, than it does to keep any given desktop session locked, I have now enabled <Ctrl>+<Alt>+Backspace from my KDE Settings, which is where we enable it now, as the definitive way to force restarting the X-server. Now, it could be that with hung log-outs, I may get to log back in, without actually requiring a System Restart, in certain cases.

Dirk

Note: When I give the command from the GUI, to my Laptop named ‘Klystron’, to “Restart”, I often notice a ‘Stop Job Running For User Dirk – 90 Seconds’. But what I have just come to realize tonight, is that each of these situations corresponds, to the hung attempt just to Log Out a Session, like on my Desktop named ‘Phoenix’. Only, I have never seen any need for the maneuver to Log Out, a Session on my Laptop, which is generally more convenient just to Restart.

Also, a full Reboot of the Laptop is about 10x faster that it is on ‘Phoenix’, due to the newer, faster CPU on the Laptop.