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.

 

Botched Update, Minor Blog Disruption

I host this blog on my own server. Further, I use a blogging engine the name of which the reader can see plainly on the site, which is partly installed via the Debian package manager, and partly via in-place downloading and updating of extensions via plug-ins.

Just tonight, the Debian team put through a package-originated update to ‘WordPress.org‘, which has happened smoothly in the past, and the nature of which I have integrated with my particular site quite well.

But immediately after the WordPress.org update tonight, the blog went off-line briefly, and I feared the worst – that I had made chopped beef out of my local configuration of files.

But what I found instead, this time around, dismayed me: In the file named


/usr/share/wordpress/wp-includes/functions.php

There is a re-declaration of three functions, in principle:


wp_json_encode()
_wp_json_sanity_check()
_wp_json_convert_string()

Since these three functions have been redeclared within the same code file, that belongs to


/usr/share/wordpress

And belonging to the package, there was no way the blog could have sent off any HTML at all – regardless of what my plug-in settings might have been. It is baffling that Debian Team would make the error, of declaring the same functions twice within the same file.

I simply had to comment out the offending functions, and my blog works again, plug-ins, theme and all.

So it would seem that the code that keeps WordPress.org running, is malleable after all, so that I was able to restore order within my files.

Dirk

(Edit : ) I suppose that for the next few hours or days, the readers might notice that the blog engine is rather sluggish. This is due to the fact that I needed to clear my cache. But clearing the cache on this server would have been necessary anyway. I had the whole maneuver planned out so carefully – To put the blog into maintenance mode, to clear the cache, to change a directory permission, to apply the update, to re-owner the folders, and to deactivate maintenance mode…

Such a shame the the code did not play nice this time.

This affected the blog from about 21h30 until 22h45.