Log-Out | Dirk Mittler's Blog

‘kded5′ Daemon suddenly taking up 80-90% of my CPU time.

This posting states an observation I made about the computer I name ‘Phosphene’, which has ‘Debian 9 / Stretch’ running on it, with the ‘Plasma 5.8′ desktop manager. With all the software I have running on it, it runs both a ‘kded4′ and a ‘kded5′ daemon, the latter of which holds together my whole Plasma 5 desktop communications. The problem has already been observed on other people’s Linux computers, that a condition can set in, in which the ‘kded5′ daemon suddenly takes up all the CPU time, and an increased amount of RAM. Phosphene possesses 12GB or RAM, so that this latter aspect of the malfunction is not usually an immediate threat.

Phosphene possesses 8 virtual cores threaded as 4, and has had such malfunctions rarely, in which each of its 8 cores seems ~80% busy.

The way Plasma 5 works is such, that this daemon runs numerous modules, any one of which could malfunction in a way that causes a similar malfunction of the daemon. The devs considered that it would be wasteful to run all the modules – Plasma 5 services – in separate processes. And so, whether this phenomenon sets in on any one computer, and if it does, which module is at fault, can vary in an individual way, from one computer to the next. But one fact which is also known is that the set of services / modules that load at boot-time may not depend on any one user’s configuration files, but may depend on what extensions and widgets are installed system-wide. Therefore, certain combinations of installed packages can leave computers with ticking time-bombs.

Once the malfunction starts, the only effective way I know to recover from it is, to reboot. Linux users don’t like to reboot.

But I think I have identified a series of (normal) actions on my part that actually triggers this. Therefore, if the reader’s Linux computer has been suffering from this very type of malfunction, then the same cause might be triggering it on his computer…

Continue reading ‘kded5′ Daemon suddenly taking up 80-90% of my CPU time.

My First Impressions of the New Plasma 5

One of the facts which I’ve been blogging about, is that I have erased Windows from a computer I had, which at the time was named ‘Mithral’, and that I had then installed Debian / Stretch on it, at which point I also changed its name to ‘Plato’. Debian / Stretch is the successor to Debian / Jessie, the latter of which I still have installed on two of my computers.

One of the main differences between the Debian / Stretch and the Debian / Jessie code-repositories is, that the newer Debian / Stretch is based on the desktop manager ‘Plasma 5′ – assuming we choose that desktop-manager – while Debian / Jessie was still based on ‘KDE 4′ as its desktop manager. And so one aspect of my ‘new’ Debian / Stretch system which I’ve been curious about – and anticipating – was how I’ll like Plasma 5 as opposed to KDE 4.

One of the facts which should be noted, is that although Plasma 5 has been altered enough to create major version issues with KDE 4 builds of applications, Plasma is not really that different, finally, from KDE 4.

The developers have focused on simplifying the experience. KDE 4 had almost unlimited options by which the user could fine-tune the appearance of his desktop, while Plasma 5 has reduced the number of settings. And yet I find, I can still do everything under Plasma 5, that I was used to doing under KDE 4. I do not necessarily need to be able to fine-tune, how translucent the Task-Bar is – which under Plasma 5 or KDE 4 specifically is named a ‘Panel’ – while its center-region, where entries exist for applications currently running in user-space, is actually named the ‘Task-Switcher‘. Linux people are sometimes particular about not wanting to seem to be copying the conventions of some other O/S.

Under Linux, we have a variety of methods, to display what processes are occupying the CPU, one of those being the command-line ‘top’, and another being the slightly-more-colorful, but still text-based command ‘htop’. We refer to htop as a ‘Process Viewer’.

One detail which went a bit far for me however, was the degree with which the default Theme – named ‘Breeze’ – made the icons and widgets seem uninteresting. From a package-manager, we can still install a throwback ‘Oxygen’ Theme, the appearance of which is more-similar to how KDE 4 looked. But if we choose the Oxygen Theme, then the default assumption would be that we want our desktop to have a dark look. I actually bypassed this result, by choosing my Look And Feel to be Oxygen, but by choosing my Desktop Theme to be ‘Air’, from the System Settings center. Air is what’s keeping the background-colors of most of my desktop bright-looking.

Also, I always took care to keep wallpapers which I had chosen, and not to allow any switch in Themes to replace those, since a bright-looking wallpaper is also necessary, for obtaining a Desktop Appearance which is bright-looking.

Continue reading My First Impressions of the New Plasma 5

Casual Maintenance today – No Worries

I apply the unusual procedure, of hosting this Web-site and blog, on a personal computer at home, which I name ‘Pheonix’ on my LAN, and not on a professional hosting-service. What this results in is a personal computer, which has an unusually large amount of RAM dedicated to non-user processes, such as for instance the Apache Web server, the MySQL server, and various other services that assist in hosting the actual site, while also assigning much RAM to my user-space processes, that create a full KDE desktop-session.

It would be an oversimplification to say, that the system-services actually run as root, because many of them switch from root to a different user-name, that just exists for one Web-service to run, but which is not root, simply to protect my computer against eventual hacking-attempts. For example, if my Web-server was to run entirely as root, and if a hacker was able to find a PHP-scripting vulnerability, he could get the thread in question to vandalize my whole computer. But in reality, the Apache thread he’d be hijacking runs with limited privileges…

One of the facts about this setup that is not ideal, is that the user-space processes that create my desktop-session, from my perspective in the foreground, actually take up more RAM than my Web-services do, just because I have such an extensive KDE setup, with PIM-services etc.. What actually happens is that as this user-session continues to run, there is a miscellanea of memory-leaks within, due to which more and more virtual addresses are allocated. Fortunately, because this is also a 64-bit system, the risk is very small, that it could actually ‘run out of 64-bit numbers’ to assign. But what this does also mean, is that an increasing amount of data – most of that presumably garbage – gets swapped out into my swap-partition over time.

This can make me feel uncomfortable, because when and if the next power-failure hits, I could lose data, simply because data which was not garbage, could be swapped-out at that moment. So when this type of imbalance has reached a certain point, what I tend to do is a log-out / log-in. This maneuver does not really reboot the computer, unmount my file-systems, or restart the kernel. It just tells my extensive desktop-session to save all its data to permanent files and databases, to exit, and then to restart. My system-processes continue to run, unaffected. Therefore, the visibility of my site, and of this blog, are not affected at all, when I do this, as long as the procedure went smoothly.

This afternoon, I enacted this procedure, and it went smoothly.

Continue reading Casual Maintenance today – No Worries

Successful X-server Update Today

Today the Debian / Jessie package maintainers pushed through an update to my X-server, bringing that up to version ‘2:1.16.4-1+deb8u1‘. In a case like this, it’s better to restart the session, just to load the new X-server version, but also, to make sure that any problems in running the X-server do not take us by surprise, during some later reboot.

As it happens, the computer this took place on, which I name ‘Phoenix‘, is also my Web-server. And so it’s desirable to perform the restart of the session, without doing a full reboot of the computer. Under Linux, with the ‘KDE’ desktop manager, we can do this by just Logging Out, and then Logging back In. Doing so also causes an X-server restart.

Not doing a full reboot of my computer, also meant that my Apache Web-server continued running, without causing any disruption to the visibility of my Web-site, or of this blog.

Yet, there was a glitch. As I told my user-session to log out, the display hanged, with the mouse-pointer still visible, but with the rest of my display black, and with no further activity on the hard-drive. In this situation I can help myself, by using the KDE, <Ctrl>+<Alt>+Backspace key-combination, to force an X-server restart. Doing so successfully ended my user-session. Then, the X-server restarted, and I got to log back in.

What this means is that the preparatory work I did according to this earlier posting, has paid off.

I count this as a successful update.

Dirk