## Plausible does not mean Assumed

I could make hypothetical guesses, as to why crashes like this one happen, on the machine I name ‘Phoenix’, which was manufactured in 2008. This time I noticed, that the cursor on the screen stopped moving, then that mouse-input was not being interpreted, then that the screen just filled with an image, which was a diagonally-scrambled version of the normal screen content:

• It could be that the old GPU is no longer reliable at the hardware level, and that it may now suffer from random crashes, which also crash the X-server. The “” (‘‘) feature I have seen the nVidia Driver execute properly in past situations, may just not kick in.
• When I reinstalled, replacing the old 32-bit O/S with the current 64-bit O/S, I also replaced the 2GB of RAM with completely new, 4GB of RAM, and the “” (‘‘) of the new RAM has also become faster, that becoming 800MHz instead of the earlier 600MHz. Either set of DDR RAM modules was running with dual-channel capability. The motherboard may detect this capability of the new RAM modules and start using it, as the motherboard itself may have the stated capability of running at 800MHz. Yet, at 800MHz, the way this Motherboard works may not be stable.
• There could be some sort of kernel issue…

What I do find a bit more specific, is the fact that there seem to be no log entries for the , suggesting that although an X-server crash eventually takes place, this may not be the root cause. Also, the fact that the mouse has become unresponsive for a few seconds, before screen-content collapses, seems to suggest the same thing…

But the most important fact for me to observe, is that simply being able to suggest plausible reasons for the crash, is not the same thing as having diagnosed the crashes. Honestly, I do not know at present, why this type of crash happens.

One of the observations about this machine which had impressed me in the past, was that I had pushed 3D rendering beyond the limits of the old GPU, thereby crashing this graphics chip, but that the desktop manager I had in place was able to restart the GPU, and to resume the session, without requiring any action from me, but displaying a well-behaved message to the effect that the GPU needed to be rebooted. This is called “” (‘‘), and does the same thing under Linux, that it does under Windows, and depends on stable graphics drivers.

The fact that I do possess ‘‘ on this machine suggests, that a simple failure of the graphics chip, should not take out my session.

According to my latest inquiry, this Motherboard is ‘only’ running at 66MHz. Therefore, the maximum speed of the newer RAM Module should not be an issue after all.

Dirk

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

## 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) evdev: HID 062a:0000: Close
[166958.723] (II) evdev: Power Button: Close
[166958.723] (II) evdev: Power Button: Close
[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.

## I have managed to make OpenShot more stable under Linux.

In a previous blog posting, I had reported that OpenShot was dangerously unstable, and even unstable under its native Linux. I’m basing this on OpenShot 1.4.3, installed from the package manager under Debian / Jessie, with a KDE 4.14 desktop.

This Was The Posting.

It turns out that there can be ways to overcome this instability.

Firstly, I have changed the Output Mode, with which this application renders its previews, from “sdl” to “sdl_preview“.

More importantly there seems to be a detail in its practical use, which I was unaware of before. Earlier, I had imported a captured .OGG / .OGV file into its video clip resources. In itself this presents a problem, in that certain .OGV Theora files, especially ones produced by screen capture, are known to give this program problems. This can be anticipated, by the video clips in question having blank thumbnails.

On the first try, I told OpenShot to play the video clip anyway in its preview window. The progress bar went from the beginning to the end at the correct speed, but once it reached the end, the application became unresponsive and KDE had to shut it down forcibly. This was with the Output Mode still set to “sdl“.

Apparently, once OpenShot has crashed, it has saved corrupted information into the folder ‘~/.openshot‘ . Had I known this, I could have deleted that folder completely before trying out the application again. But instead I tried to use OpenShot again right away, sometimes telling it to play the .MP4 version of the same video or other clips.

That was when my desktop froze. The X-server did not crash, but no movement or mouse input could be given anywhere on the desktop. The actual mouse pointer was still moving in response to the mouse however, and it was also changing from the usual pointer, to the special pointer when hovering over the preview panel. I needed to use <Ctrl>+<Alt>+F1 in order to open a Virtual Terminal in text mode, and then to ‘kill -9‘ the actual application pinning the other virtual terminal.

My setups typically allow for multiple sessions to be logged in at once, and Virtual Terminals 1-6 are text-based, while the graphical ones start from Virtual Terminal 7. So once the offending processes were killed, I was able to <Ctrl>+<Alt>+F7 back into the graphical session, which was not corrupted.

But the way I finally broke this spell with OpenShot, was to delete the directory ‘~/.openshot‘ and its corrupted contents. After that, the application was able to play the .MP4 video clips fine, which also had thumbnails that corresponded to their content.

Also, if I decide that a user-space configuration is needed to ensure the stability of the system, I copy the contents of the configuration folder for one application, into ‘/etc/skel‘, from where a skeleton of starting files is copied, every time the home directory of a new user is set up. That way, any newly-installed user will inherit my recommended settings.

In order to do that, after I deleted the config folder once, I only launch the application briefly, and make my configuration settings, before exiting the application again immediately. At that point I feel that the config folder is in its correct state, to be copied to ‘/etc/skel‘ .

There are certain purposes, which OpenShot may be better able to suit than alternatives, simply because OpenShot has more features.

Dirk