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…