Troubleshooting kded4 Bugs

Not just recently, but as long as KDE exists, we are getting bug reports for the KDE process “kded4“. These include:

• kded4 crashes
• kded4 leaks memory
• kded4 eats 100% CPU
• kded4 <defunct> process

Before I dive into troubleshooting those problems, let me explain what kded4 does and how it works.

Little Demons Everywhere

In the Plasma Workspace there is a widget to show notifications when the battery goes low. But how does the widget know when this happens? It could just check the battery level every couple of seconds, but this would waste CPU cycles. Instead, many ACPI BIOS implementations can trigger hardware interrupts to notify the operating system about the battery state.

Now Plasma could connect to the OS directly, but this would mean it will not run on other operating systems. The solution is a daemon which has OS specific backends. They watch those OS signals and Plasma can connect to the daemon’s interface (usually via D-Bus) to learn about the battery’s health.

Thus a daemon is small process that often just sits there and waits for OS events and triggers simple actions. KDE needs daemons to watch the network, the printer ports, the screen brightness hotkeys, the mounted disks, etc.

With the numbers of daemons we need, but with the very little work they do, it makes sense to use a single process for all of them. The key advantage is less memory usage, and this is exactly what kded4, the KDE daemon process, exploits: To enable the various daemon functionalities, it loads specialized kded modules instead of needing a separate process for each of them.

The Crux of kded4 Bugs

The downside of this approach is that bugs in any of those modules can be fatal for the complete process; in other words, every module must function correctly for kded4 to operate successfully. Which brings us back to the bugs: Some modules still have issues.

Lets say someone reports a problem about growing kded4 memory usage. With the above description in mind, it is easy to understand that – without further analysis – the bug could be in any module, or even in multiple of them. Since the set of modules that developers use might be different than what the reporter used, and the daemons often only handle very seldom actions, many issues cannot be reproduced easily, and without some help from the bug reporter, those problems often cannot be fixed.

The following checklist should guide you through the steps required to troubleshoot kded4 bugs and help collecting information needed to fix them.

Make Sure the Bug is Reproducible

Some bugs only show once. You installed an update, and on next reboot, kded4 crashes, maybe because some configuration files were not correctly updated yet. On subsequent reboots, it works fine without a crash. What to do? Most people do not save previous configuration files, so even when going back to the old version before the update, the crash might never happen again.

You plugged in a headset, and kded4 starts consuming 100% CPU cycles, maybe because a new device triggers a bug in underlying Phonon modules. If you restart, this bug never happens again, because Phonon might “remember” the headset, and not trigger the bug on this code path. Worth a report?

You log out of KDE, noticing you have hundreds of hanging (defunct) kded4 processes lying around. After killing them all and logging in again, there is only a single kded4 process, and that correctly terminates on logout, so you might think the problem was only temporary. The reason is that the process might only hang when a module performs a certain action; it is never the logout per se that makes kded4 hang.

Related are problems that show when kded4 hangs or does not run at all. The symptoms are often completely unrelated. For example, people notice cookies in Konqueror not working, and the usual cause is kded4 not running. Some module might prevent it from starting, or cause it to hang, e.g. waiting for an event that never happens. Of course, these issues should also be fixed.

If you want to report such a bug, make sure you can reproduce it. Try finding old configuration files, try reverting to previous versions, try to find out what steps or actions are required to trigger it. Use the top console command to verify if kde4 really consumes CPU cycles or eats memory. If you cannot reproduce, there is little chance we can. Bugs that never go away are easier, but that does not imply we can see them, too.

Isolate the Offender

The next step is to find out which module is responsible. Without this information, there is often little we can do.

Disable kded4 modules in System Settings > Startup and Shutdown > Service Manager. Some modules cannot be disabled there or automatically start even if you disabled them. To disable such a module, remove its .desktop file from /usr/share/kde4/services/kded/, run kbuildsycoca4, and restart kded4. (Move them to a place where you can easily restore them. This requires root privileges.)

Regularily retrying to reproduce the bug with some modules disabled should eventually lead to the offender. Of course you should start with the “obvious” candidates. For example, if a problem shows when plugging an audio device, the fault is very likely in the phononserver module. For crashes, the offending module can often be found in the complete backtrace.

But sometimes the bug is only triggered by specific combinations of modules, so some patience trying to find them certainly helps. If the problem is reproducible regardless of modules, the bug might really be in kded4 itself, but this is very unlikely from looking at last years bug reports.

Check Existing Bugs

Before filing a new bug report, you should check existing reports for similar or identical problems. If you add a comment with your findings it may be the determining factor for fixing the bug. If you found no similar report, add a new one. Ideally you report it against the module which is responsible.

Note that some distributions might add additional distribution specific modules, in particular to check repositories for software updates. Bugs for those modules should be reported to the bug tracker of your distribution.

In any case, if you are not sure about any of above steps, you might contact KDE forums to ask for help. Even if you cannot provide all required information, it is better to write a report for a new bug, instead of hoping someone else does. Only if you want to see it fixed, of course.