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…
I should mention that I have the “Baloo” file indexer installed and working, as far as I can tell, correctly. What it does isn’t liked by many Linux users, which is, to create a database of targeted, user folders, that can be used from within the ‘Dolphin’ file manager, to accelerate searches for files, both according to file-name and contents. In fact, Baloo can be made to extend its search capabilities, to look inside unexpected files such as images, and I have that feature installed, too.
Most Linux users would not even activate such a thing, because they dislike being tracked, even by their own software. I find it to be a handy tool at times.
Baloo is to be configured such that, although it searches the user’s entire home directory, with its sub-directories, by default, it is given a set of folders not to scan, by each user, according to that user’s wishes. I have a set of folders configured in this way, including a ‘~/Programs’ folder, the entire contents of which are voluminous, but also incomprehensible to AI, because what is text will be source code, and what is not text will be binary software.
What I’ve discovered quite by accident is that, If I navigate Dolphin to a folder that is not being indexed by Baloo, and if I then tell Dolphin to search all the subfolders for files according to content, the search still works, but about 20 minutes later, the ‘kded5′ daemon goes into the described, corrupted state. If I did not know any better, I’d think that ‘kded5′ is trying to make up for the fact that Baloo has failed to index the folders searched.
I’m reasonably sure of this, because it happened to me twice in a row, in the space of a few hours this morning, when normally, it would not happen to me for months on end. And there have always been random points in time in which I used Dolphin to search sub-folders for contents, even though those folders were not being indexed. I would have done this months ago, without realizing that I had done so. And ‘kded5′ would go into its malfunction, about as infrequently.
One additional detail which did occur to me today was, that I had left the Search function of Dolphin set to ‘Contents’ instead of ‘File Names’. In order to set the preferences of the search bar back to File Names, what I just did within the past hour was, to navigate Dolphin to an empty folder, which I was sure is being indexed, to click on the spyglass-icon, and to switch the mode of the resulting toolbar back to ‘File Names’ there. This did not seem to re-trigger the malfunction.
And the computer has been idling all day without running into any problems.
Afterthought:
I suppose that the reader may wonder what the screen-shot has to do with this. In fact, this malfunction is difficult to capture in a screen-shot, and I don’t particularly want to perform more avoidable reboots.
I was pursuing a project, to custom-compile Version 1.2 of This Software, which is named ‘DJV’. It may be useful to me in the future, as a better way to view and analyze ‘OpenEXR’ (2D, Image) Files, the pixels of which are floating-point, High Dynamic Range colour-values. Ordinary 2D Image Files historically only store 8-bit integers for each channel.
That software-project required that I search the source-tree for all files that contained a certain text-string, so that I was able to right-click on those files directly within the search results, and edit them with ‘KWrite’. This was part of a successful effort, as v1.2 is now running properly.
But it was actually when doing so, that I triggered the malfunction twice this morning, that the beginning of this posting describes.
The reader can rest assured, that I can run the resulting program (‘DJV’) as often as I like, without causing any sort of malfunction that I can detect.
Dirk
