Created attachment 39331 [details]
Sysprof trace showing kded4 chewing up CPU time

From SystemSettings/Advanced tab/Service Manager, you can control the modules that KDED4 loads.
You could try to disable one by one to check if the CPU usage drops, and this way, find the culprit.
Regards

Good idea.  Unfortunately, it was less informative than I'd hoped.  Stopping all running services (except for load-on-demand services, which I couldn't find a way to stop) didn't prevent kded4 from burning up CPU time.  I rebooted with all configurable services disabled, and kded4 behaved.  I rebooted with all configurable services enabled, and kded4 *still* behaved itself.

All of which is frustratingly inconclusive!

I'll look out for the problem in future.  If I find it, is there any way to look inside kded4 and see where the CPU time is going, or will our best clue be the sysprof trace that I've already attached?

Probably David (the maintainer) can answer that.
Thanks

Hi there, Even though I am on SuSE 11.2, just an IF possibility...something else to think about. I have had, in the past, high CPU usage and the reasons were tracked down to powerdevil, primarily, and pulseaudio. You might watch those to when you have further problems. Powerdevil can be removed with no ill effects and so can pulseaudio.  Hope this helps...even if a little.

SVN commit 1075552 by dfaure:

Fix 100% CPU usage due to a startTimer(0) that was never stopped; this could
happen if the timer was started twice, so m_timerId was overwritten, and the first
timer ID never recognized. It's much much simpler to use deleteLater: no risk of forgetting
the deletion and no risk of timers running forever. It means using QWeakPointer to notice
when it got deleted, though.
CCMAIL: kretz@kde.org

I'm not sure which of the "kded uses 100% cpu" bugs this really fixes; maybe all,
or maybe just the one that talks about phonon specifically...
Fixed for: 4.4
BUG: 202744
CCBUG: 178228
CCBUG: 184576
CCBUG: 217364
CCBUG: 220047


 M  +16 -34    hardwaredatabase.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1075552

I'm not sure if this is related to this exact solution but running the command

qdbus org.kde.kded /kded unloadModule desktopnotifier

seems to fix the problem for me.

- Could anyone else check that ? Regards

I can detect this issue in KDE 4.5rc2 too. I have a i7 8x0 processor on a P55 platform, with 4 cores. When I start KDE, X consumes ~1-2% of CPU. After a dozen of minutes, this increases to ~20-30%, then after a couple of minutes this increases to 100% of one CPU core.

In this thread: http://forum.kde.org/viewtopic.php?f=20&t=82416&p=164949#p164949
someone suggests this is caused by the systray, and that removing Kontact from the systray solves the issue. This other user: https://bbs.archlinux.org/viewtopic.php?pid=640672#p640672 reports the same problem with Kalarm.

There seems to be a pattern with the systray, which I am unable to confirm at the moment for my case, but I will try to see if I solve this issue in a similar way.

(In reply to comment #8)
> - Could anyone else check that ? Regards

I have tried the command above
qdbus org.kde.kded /kded unloadModule desktopnotifier

but with no effect. This was after X was at 100%. Removing the systray from the bar did not solve it either. Any sugestion?

Actually, after moving my old .kde4 folder (which I had for a while), the problem has disappeard, even after adding the plasmoids I had before. The issue could have been caused by remainings of old settings that are incompatible with KDE 4.4.5/4.5rc ? I kept the old .kde4, but is it worth it to chase this issue now?

I face with exactly the same symptom.
After a while, Xorg eats all my CPU time and the typing on keyboard in KDE applications becomes really slow, also the moving of the windows. It does not affect google chrome for example, it remains responsive.

(In reply to comment #12)
> I face with exactly the same symptom.

Aaron: have you tried what I did (rebuild your .kde4 from scratch)?

(In reply to comment #13)
> (In reply to comment #12)
> > I face with exactly the same symptom.
> 
> Aaron: have you tried what I did (rebuild your .kde4 from scratch)?

No, but i just switched to IceWM but still using exactly the same applications (chrome, kontact, kopete, kwrite, konqueror etc.) together in the same time and i can't reproduce the slowdown anymore. So it seems it's not application specific, neither KDE library specific.

I want to confirm the xorg issue. It disapears when i close some icons in the systray. I am usen kde 4.6.0 with opensuse 11.3 and the problem began with kde4.6beta2 i believe...

*** This bug has been confirmed by popular vote. ***

Here kded4 from kde 4.6.0 eats 100% cpu doing:

[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000008>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000008>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>
[pid 21145] 16:01:54 poll([{fd=17, events=POLLIN}, {fd=16, events=POLLIN}], 2, -1) = 1 ([{fd=16, revents=POLLIN}]) <0.000007>


descriptor 16 is inotify:
lr-x------ 1 arekm users 64 02-05 15:41 /proc/21137/fd/16 -> anon_inode:inotify

but no idea what is being monitored via inotify and I cannot find a way do get that info from proc or debugfs.

More info:
(gdb) bt
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007ffc3398618b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQtCore.so.4
#2  0x00007ffc33985280 in QThread::wait(unsigned long) () from /usr/lib64/libQtCore.so.4
#3  0x00007ffc33a42b70 in QFileSystemWatcher::~QFileSystemWatcher() () from /usr/lib64/libQtCore.so.4
#4  0x00007ffc33a42c49 in QFileSystemWatcher::~QFileSystemWatcher() () from /usr/lib64/libQtCore.so.4
#5  0x00007ffc33a80bd4 in QObjectPrivate::deleteChildren() () from /usr/lib64/libQtCore.so.4
#6  0x00007ffc33a85782 in QObject::~QObject() () from /usr/lib64/libQtCore.so.4
#7  0x00007ffc26844cc9 in Solid::Backends::Fstab::FstabWatcher::~FstabWatcher (this=0x15de2d0, __in_chrg=<value optimized out>)
    at /usr/src/debug/kdelibs-4.6.0/solid/solid/backends/fstab/fstabwatcher.cpp:51
#8  0x00007ffc3240b8a1 in __run_exit_handlers (status=1, listp=0x7ffc3275f4c8, run_list_atexit=true) at exit.c:78
#9  0x00007ffc3240b8f5 in exit (status=22924428) at exit.c:100
#10 0x00007ffc32c89548 in ?? () from /usr/lib64/libQtGui.so.4
#11 0x00007ffc342bed9e in _XIOError () from /usr/lib64/libX11.so.6
#12 0x00007ffc342bcc27 in _XReply () from /usr/lib64/libX11.so.6
#13 0x00007ffc342a1633 in XGetSelectionOwner () from /usr/lib64/libX11.so.6
#14 0x00007ffc32ca0def in QClipboard::event(QEvent*) () from /usr/lib64/libQtGui.so.4
#15 0x00007ffc32c1d594 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#16 0x00007ffc32c2209a in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#17 0x00007ffc33a6e25c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#18 0x00007ffc32c2687b in QApplication::~QApplication() () from /usr/lib64/libQtGui.so.4
#19 0x00007ffc1e6cf18d in ~KDEDApplication (argc=0, argv=0x1364b70) at /usr/src/debug/kdelibs-4.6.0/kded/kded.cpp:797
#20 kdemain (argc=0, argv=0x1364b70) at /usr/src/debug/kdelibs-4.6.0/kded/kded.cpp:915
#21 0x0000000000406c9f in launch (argc=1, _name=0x40adbf "kded4", args=<value optimized out>, cwd=0x0, envc=<value optimized out>,
    envs=<value optimized out>, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40ac46 "0")
    at /usr/src/debug/kdelibs-4.6.0/kinit/kinit.cpp:730
#22 0x000000000040942e in main (argc=4, argv=0x7fff8b921198, envp=0x7fff8b9211c0) at /usr/src/debug/kdelibs-4.6.0/kinit/kinit.cpp:1845


fstab watcher doing all that cpu eating?

I had this start happening on kde 4.6 kubuntu 10.10 after I ejected a CDROM. When I tried to eject the cdrom it would eject the tray and then instantly close the tray again. After a few attempts I snatched the CD out before it closed the tray. Once the tray closed, 2 kded4 processes appeared that use 100% CPU each. I cannot reliably reproduce the kded4 processes appearing, but it definitely does suck my cd in every time if I'm not quick enough. It does appear related to some file notifier component. As for the cdrom sucked back in issue...

I'm testing:
http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/kde4-kdelibs/kde4-kdelibs-trunk.patch?rev=1.1
and so far no kded eating cpu problem.

I'm getting this occasionally with KDE trunk.  Sometimes when I attach gdb to kded and sample some backtraces (using ^C and cont), it looks like Bug 268038.  However, the most recent time, every backtrace ended somewhere in poll().

I attached sysprof to kded4, but it was completely unhelpful (I'll attach it).

Unloading all modules (including the autoload ones) did not help.

There was also no unusual D-Bus activity, so it wasn't just that some other process was calling to it over D-Bus lots.

Killing kded4 and restarting it fixes it, at least for a time: this issue happens quite haphazardly, not necessarily when kded4 starts.

Created attachment 58677 [details]
Sysprof output from when kded4 was misbehaving

Oddly, kded4 has just started behaving itself again, with me killing it - well, I sent it a SIGTERM, but not a SIGKILL, and it didn't exit, but it does seem to have gone quiet.  Although I can't say for certain that it didn't settle down _before_ I sent the SIGTERM.

Try kdelibs trunk patch. I'm only getting ntrack problem (#268038) with this applied (aka poll() problem is gone as this patch changes the way things are done).

commit 42d40d1d351588a71bef0af1d62a8f6dc586f141
Author: Mario Bensi <mbensi@ipsquad.net>
Date:   Mon Jan 31 10:28:51 2011 +0100

    Fix crash during the QFileSystemWatcher destruction
    
    The QFileSystemWatcher doesn't work correctly in a singleton
    The solution so far was to destroy the QFileSystemWatcher when the
    application quits but we have some crash with this solution.
    For the moment to workaround the problem, we detach the
    QFileSystemWatcher from the parent effectively leaking it on purpose.

(In reply to comment #23)
> Try kdelibs trunk patch. I'm only getting ntrack problem (#268038) with this
> applied (aka poll() problem is gone as this patch changes the way things are
> done).
> 
> commit 42d40d1d351588a71bef0af1d62a8f6dc586f141
> Author: Mario Bensi <mbensi@ipsquad.net>
> Date:   Mon Jan 31 10:28:51 2011 +0100
> 
>     Fix crash during the QFileSystemWatcher destruction

Whoops also this:

commit 350a5d8de016b6daa36c6e29d5d5f83ad6c2b38d
Author: Mario Bensi <mbensi@ipsquad.net>
Date:   Tue Feb 1 11:11:58 2011 +0100

    Fix solid test
    
    I need to detach parent on QFileSystemWatcher when the FstabWatcher
    destructor are called if the aboutToQuit is not called. It's the case in
    test.

This is running kdelibs, kde-runtime and kde-workspace from git master as of a couple of hours ago.

kded4 is in a continuous polling loop.  strace reports lots of:

poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}, {fd=0, events=POLLIN}, {fd=18, events=POLLIN}], 10, 0) = 1 ([{fd=0, revents=POLLHUP}])
read(8, 0x20e5a94, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x20e5a94, 4096)                = -1 EAGAIN (Resource temporarily unavailable)

This just happens continuously, and (judging by sysprof) is what is causing it to hammer the cpu, while at the same time not making kded4 unresponsive.

% ls /proc/32309/fd -l
total 0
lr-x------ 1 alex users 64 Apr  7 19:23 0 -> pipe:[1096927]
l-wx------ 1 alex users 64 Apr  7 19:23 1 -> /home/alex/.xsession-errors
lr-x------ 1 alex users 64 Apr  7 19:23 10 -> anon_inode:inotify
lr-x------ 1 alex users 64 Apr  7 19:23 11 -> /var/tmp/kdecache-alex/ksycoca4
lrwx------ 1 alex users 64 Apr  7 19:23 12 -> socket:[1096991]
lrwx------ 1 alex users 64 Apr  7 19:23 13 -> socket:[1097071]
lrwx------ 1 alex users 64 Apr  7 19:23 14 -> socket:[1097076]
lr-x------ 1 alex users 64 Apr  7 19:23 15 -> anon_inode:inotify
lr-x------ 1 alex users 64 Apr  7 19:23 16 -> pipe:[1097077]
l-wx------ 1 alex users 64 Apr  7 19:23 17 -> pipe:[1097077]
lrwx------ 1 alex users 64 Apr  7 19:23 18 -> /dev/snd/controlC0
lr-x------ 1 alex users 64 Apr  7 19:23 19 -> /dev/urandom
l-wx------ 1 alex users 64 Apr  7 19:23 2 -> /home/alex/.xsession-errors
lr-x------ 1 alex users 64 Apr  7 19:23 3 -> pipe:[1095328]
l-wx------ 1 alex users 64 Apr  7 19:23 4 -> pipe:[1095328]
lrwx------ 1 alex users 64 Apr  7 19:23 5 -> socket:[1095327]
lr-x------ 1 alex users 64 Apr  7 19:23 6 -> pipe:[1095330]
l-wx------ 1 alex users 64 Apr  7 19:23 7 -> pipe:[1095330]
lrwx------ 1 alex users 64 Apr  7 19:23 8 -> socket:[1095331]
lrwx------ 1 alex users 64 Apr  7 19:23 9 -> socket:[1095334]

There doesn't seem to be any straightforward way to find out which process has the other end of socket:[1095331], though.

With all kded4 services stopped, strace puts out exactly the same output.

I also tried using gdb to catch the poll syscall, and also break on the poll method in libc.  I get this pattern repeated continuously (once I allow the X events that were queued up whilst kded4 was paused by gdb to be dealt with).

Catchpoint 2 (call to syscall 'poll'), 0x00007f080f89e533 in poll () from /lib/libc.so.6
#0  0x00007f080f89e533 in poll () from /lib/libc.so.6
#1  0x00007f080c1a0134 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f080c1a066d in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f0811569a0f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f081078c03e in ?? () from /usr/lib/libQtGui.so.4
#5  0x00007f081153dca2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f081153deec in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#7  0x00007f08115423eb in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#8  0x00007f08009fd4dc in kdemain (argc=1, argv=0x20897d0) at /home/kde-devel/src/kdelibs/kded/kded.cpp:925
#9  0x00000000004072c4 in launch (argc=1, _name=0x208c1e8 "kded4", args=0x208c1ee "", cwd=0x0, envc=0, envs=0x208c1f6 "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40cf75 "0") at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:734
#10 0x00000000004083fa in handle_launcher_request (sock=15, who=0x40d204 "wrapper") at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1226
#11 0x0000000000408c3c in handle_requests (waitForPid=0) at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1410
#12 0x000000000040a756 in main (argc=4, argv=0x7fffd88a4428, envp=0x7fffd88a4450) at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1907

Catchpoint 2 (returned from syscall 'poll'), 0x00007f080f89e533 in poll () from /lib/libc.so.6
#0  0x00007f080f89e533 in poll () from /lib/libc.so.6
#1  0x00007f080c1a0134 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f080c1a066d in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f0811569a0f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f081078c03e in ?? () from /usr/lib/libQtGui.so.4
#5  0x00007f081153dca2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f081153deec in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#7  0x00007f08115423eb in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#8  0x00007f08009fd4dc in kdemain (argc=1, argv=0x20897d0) at /home/kde-devel/src/kdelibs/kded/kded.cpp:925
#9  0x00000000004072c4 in launch (argc=1, _name=0x208c1e8 "kded4", args=0x208c1ee "", cwd=0x0, envc=0, envs=0x208c1f6 "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40cf75 "0") at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:734
#10 0x00000000004083fa in handle_launcher_request (sock=15, who=0x40d204 "wrapper") at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1226
#11 0x0000000000408c3c in handle_requests (waitForPid=0) at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1410
#12 0x000000000040a756 in main (argc=4, argv=0x7fffd88a4428, envp=0x7fffd88a4450) at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1907

Breakpoint 3, 0x00007f080f89e4e0 in poll () from /lib/libc.so.6
#0  0x00007f080f89e4e0 in poll () from /lib/libc.so.6
#1  0x00007f080c1a0134 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f080c1a066d in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f0811569a0f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f081078c03e in ?? () from /usr/lib/libQtGui.so.4
#5  0x00007f081153dca2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f081153deec in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#7  0x00007f08115423eb in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#8  0x00007f08009fd4dc in kdemain (argc=1, argv=0x20897d0) at /home/kde-devel/src/kdelibs/kded/kded.cpp:925
#9  0x00000000004072c4 in launch (argc=1, _name=0x208c1e8 "kded4", args=0x208c1ee "", cwd=0x0, envc=0, envs=0x208c1f6 "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40cf75 "0") at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:734
#10 0x00000000004083fa in handle_launcher_request (sock=15, who=0x40d204 "wrapper") at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1226
#11 0x0000000000408c3c in handle_requests (waitForPid=0) at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1410
#12 0x000000000040a756 in main (argc=4, argv=0x7fffd88a4428, envp=0x7fffd88a4450) at /home/kde-devel/src/kdelibs/kinit/kinit.cpp:1907

Looking again at the strace output, fd 0 (ie: standard in) appears to be getting POLLHUP ("The device has been disconnected") when it is polled.  Could this be the issue?

I was wrong about this, by the way - the Network Status module is at fault for me.  However, stopping it via the D-Bus interface or the kcm does not help.  Starting kded4 with it disabled (and with autoloading turned off!) prevents kded4 from consuming lots of CPU, though.

I'm actually getting Bug 268038.  I don't know about other people on this bug.

(Sorry for all the comment spam)

I am the same problem when unplugging my "Mobile Broadband". 100% CPU for kded4.

Using:
ArchLinux
KDE 4.6.2
Qt 4.7.2

I have the same kded4 problem, both when disconnecting mobile broadband and VPNs, and several other have it too, at least according to a kubuntu forum - http://kubuntuforums.net/forums/index.php?topic=3116537.0 . It happens also on kubuntu live cds, with a "clean" .kde.

Bringing some extra info:

The same issue was occurring here (Kubuntu 11.04) when running Ktorrent and enabling/disabling VPN connections.

After reading many kde tips to fix this, Kded4 cpu usage finally reduced to normal levels since I ran the following steps:

1. install the proprietary driver for my Nvidia card (GF 9400M G)
2. disable some startup services
  - Power Management
  - Status Notifier Manager
  - Free Space Notifier

hope to help you guys!

*** Bug 253606 has been marked as a duplicate of this bug. ***

I've always used nvidia's proprietary driver
I use a desktop with only amd's powernow (kernel level) power management
I'm not going to disable the status notifier as it is a critical process
I don't run the free space notifier.

I get the 100% cpu on body kded and knotify about once every 2-3 weeks and have ever since moving to kde4.4 from kde3.5.

I get this bug on every single login with usually a plugged in usb device - either a usb ram stick or a usb 3g modem. I end up killing off one kded4 after another manually and eventually services stop working like kmail's wallet for ssh certificates or what not and I end up having to give up on kde. Given this is a laptop I'm on, this problem has turned into a showstopper for me since it's basically impossible to have any decent battery life with this firing off regularly. I'm now on ubuntu 11.04 with its latest kde packages (4.6.2b?) and the problem appears worse if anything.

(In reply to comment #35)
> I get this bug on every single login with usually a plugged in usb device -
> either a usb ram stick or a usb 3g modem. I end up killing off one kded4 after
> another manually and eventually services stop working like kmail's wallet for
> ssh certificates or what not and I end up having to give up on kde. Given this
> is a laptop I'm on, this problem has turned into a showstopper for me since
> it's basically impossible to have any decent battery life with this firing off
> regularly. I'm now on ubuntu 11.04 with its latest kde packages (4.6.2b?) and
> the problem appears worse if anything.

Your problem is probably this one: http://bugs.kde.org/show_bug.cgi?id=268038

Ntrack is the culprit, since KDE's networkstatus module in (K)Ubuntu is compiled against ntrack the only workaround is disable networkstatus module by for examploe moving the file /usr/lib/kde4/kded_networkstatus.so to somewhere else.

I often get this problem when mount usb stick.
Today it happened after I mounted a TrueCrypt volume.

KDE 4.6.4, Kubuntu 11.04 32 bit

I am using KDE-4.6.3 (Mageia release 1 Official) and I see this high CPU usage everytime I login and use KDE. After KDE starts, its ok but soon after, say, playing some video using mmplayer (or flash video on youtube in firefox), KDE processes and X start taking a lot of CPU (I have seen 11+ loads on my dual-core laptop). I have tried quitting KDE (I use run-level 3) and restarting KDE but the problem dis not go away. I even killed the kded process and still the system load is close to 1 always. The KDE services I have running are very few. I even manually quit the network manager and kmix and still the problem continues.

Dial up user here is having same problem.  I have a desktop setup. Kernel 2.6.37.6, KDE 4.6.5, dbus 1.4.1, qt 4.7.2, hal 0.5.14, N.M. 0.8.4.0, plasma-applet-networkmanagement 0.0_20110804 using Pardus operating system.  I have an external USB /dev/ttyACM0 56K modem. My ISP uses a dynamic IP address.  I've used kppp and wvdial for over seven years with no problems.  There are still lots of us that do not have a choice.  I can't use NetworkManager to set up a connection, as it does not have a way to select my device (ttyaACM0).  
Using kppp dial up utility and sometimes wvdial:  All is well when I connect, surf the internet, disconnect, let monitor go to sleep, wake it up, all is still well.   I reconnect using kppp and at instance the connection is made, that is when CPU usage for kdeinit4: kded4 [kdeinit] shoots to top of Htop process viewer, showing 50%, then 90%, 95%, 60%, 92% and stays there fluctuating.  During this time certain programs become slow to appear when I click on them, such as Konqueror, or PiSi Package Manager, Dolphin File Manager.  and Shutdown/Restart.  I use nouveau for video. I've tried turning off desktop effects, but that did not help.  I changed backend from NetworkManager to FakeNet.  Did not help but Fakenet is not installed on this OS. I try to go to System Settings>Startup and Shutdown> I cannot click on Service Manager and get a "Program is not Responding" or Kded is not running in a pop up.  Go to Htop and select the kdeinit4 process and sigkill it, a kde crash handler window pops up "kde daemon - kde crash handler
executable: kdeinit4 PID: 1022 Signal: Illegal instruction (4)".  This process is user process, not root.  All is well after doing this. 
I don't know if it is related, but when I use wvdial, when I want to disconnect by hitting Ctrl + C, it does not work.  I have to "sudo pkill pppd" to disconnect.
I have tried lots of work arounds, but none worked: stop NetworkManager and wpa_supplicant, stop Nepomuk and strigi, stop Aavhi-daemon, and did so upon reboot as many of these start whether you have them selected in Service settings to not start.  I then manually disabled Akonadi, disabled all programs under Kontact except for Journal, emptied /var/tmp file and ~/.cache files, manually stopped Nepomuk, and still problem exists.  Then, edited as root to change "true" to "false" in some of the autostart .desktop files, but didn't work. I finally tried the hard-hammer approach and using Dolphin as Root, I unticked "is executable" of programs I suspected were causing the problem: NetworkManager, modem manager, wpa_supplicant, and all of the bin exe's for Akonadi.  This last fix seemed to work.   
Certainly, killing the process works after the problem starts.  As soon as I do that, the kde programs work normally, until the next login.

Created attachment 62665 [details]
live outpupt of kdeinit4 in konsole

I entered kdedinit4 in terminal to see what kind of output I would get before and after the CPU fluctuating began when I disconnected my ppp connection.  I don't know if it helps, but hope it does.

I wanted to report that I am also seeing this problem with KDE 4.6.5.

I'm also experiencing this problem since KDE 4.7.0 (openSUSE 11.3 x86_64).

My .kde4 directory is brand new because KDE 4.7 completely crashed with the old one. I don't use any plasmoid and most KDE services are disabled since I don't use them (nepomuk, akonadi, monitor/hardware detection, etc. etc.). Turning them on/off seem to have no effect. Below is an image of the services I'm running.

Created attachment 62923 [details]
Services currently running

hi alvaro,

If you use the openSUSE KDE 4 Factory repository, probably the culprit is

kded_networkstatus.so

coming from kde4-runtime package 4.7.0 build 320.1

Following workarounds are possible:

1. Use the file from the kde4-runtime package 4.7.0 build 297.1
2. Deactive the networkstatus service, e.g. through moving out networkstatus.desktop file from /usr/share/kde4/services/kded/

hope that helps
  harald

hi harald,

I didn't try replacing the file yet, but disabling the network status seems to work. The problem is that without this service, the networkmanager doesn't work, which is one of the few things I actually need.

anyway, thanks for your help!
alvaro.

(In reply to comment #42)
> I'm also experiencing this problem since KDE 4.7.0 (openSUSE 11.3 x86_64).
> 
> My .kde4 directory is brand new because KDE 4.7 completely crashed with the old
> one. I don't use any plasmoid and most KDE services are disabled since I don't
> use them (nepomuk, akonadi, monitor/hardware detection, etc. etc.). Turning
> them on/off seem to have no effect. Below is an image of the services I'm
> running.

Alvaro, we fixed this problem in KDE:Distro:Factory but it'll take time until packages for 11.3 published.

You can try manually removing the following packages: libntrack-qt4-1, libntrack0, and ntrack-libnl1 . You have to ignore dependency problems and force remove.

Its a band-aid until new packages are published.

Thank you Ismail, your workaround works perfectly.

(In reply to comment #46)
> (In reply to comment #42)
> > I'm also experiencing this problem since KDE 4.7.0 (openSUSE 11.3 x86_64).
> > 
> > My .kde4 directory is brand new because KDE 4.7 completely crashed with the old
> > one. I don't use any plasmoid and most KDE services are disabled since I don't
> > use them (nepomuk, akonadi, monitor/hardware detection, etc. etc.). Turning
> > them on/off seem to have no effect. Below is an image of the services I'm
> > running.
> 
> Alvaro, we fixed this problem in KDE:Distro:Factory but it'll take time until
> packages for 11.3 published.
> 
> You can try manually removing the following packages: libntrack-qt4-1,
> libntrack0, and ntrack-libnl1 . You have to ignore dependency problems and
> force remove.
> 
> Its a band-aid until new packages are published.

That shut down kdeinit4 for me, thanks.  And my laptop is nice and quiet.

However, knotify4 is still consuming a few % of CPU, in what looks like a very similar poll loop:

14:15:32.974162 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=16, events=POLLIN}, {fd=18, events=POLLIN}, {fd=5, events=POLLIN}, {fd=19, events=POLLIN}, {fd=17, events=POLLIN}], 9, 49) = 0 (Timeout)
14:15:33.023346 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.023415 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.023471 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=16, events=POLLIN}, {fd=18, events=POLLIN}, {fd=5, events=POLLIN}, {fd=19, events=POLLIN}, {fd=17, events=POLLIN}], 9, 0) = 0 (Timeout)
14:15:33.023547 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.023607 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.023661 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=16, events=POLLIN}, {fd=18, events=POLLIN}, {fd=5, events=POLLIN}, {fd=19, events=POLLIN}, {fd=17, events=POLLIN}], 9, 0) = 0 (Timeout)
14:15:33.023735 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.023867 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.023930 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=16, events=POLLIN}, {fd=18, events=POLLIN}, {fd=5, events=POLLIN}, {fd=19, events=POLLIN}, {fd=17, events=POLLIN}], 9, 49) = 0 (Timeout)
14:15:33.073113 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.073181 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.073237 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=16, events=POLLIN}, {fd=18, events=POLLIN}, {fd=5, events=POLLIN}, {fd=19, events=POLLIN}, {fd=17, events=POLLIN}], 9, 0) = 0 (Timeout)
14:15:33.073314 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.073651 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.073750 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=16, events=POLLIN}, {fd=18, events=POLLIN}, {fd=5, events=POLLIN}, {fd=19, events=POLLIN}, {fd=17, events=POLLIN}], 9, 0) = 0 (Timeout)
14:15:33.073849 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
14:15:33.074017 read(8, 0x6675b4, 4096) = -1 EAGAIN (Resource temporarily unavailable)

The latest OpenSUSE 4.7.0 bits appear to resolve this.  knotify4 is still doing its background loop.

What is the status of this bug? Since the Ntrack/network related CPU spikes are fixed upstream, is there any other kded4 problems?

I'm still on 4.6.2 and it looks ok on my system. Haven't been able to get the newest SuSE 12.1 and KDE 4.7 to work. Waiting to see if the Beta is better then I could report on it. (problems on the latest are nVidia drivers not working on my 7300 LE card)
Thanks,
Chuck

I originally posted under comment #39 a dial up user.  This week I received Fedora 15, installed KDE desktop default version 4.6.2.  Did all updates and downloaded and installed KDE 4.7.1 as instructed at Fedora forum.  
I am happy to say I am no longer having the CPU spiking problem if I am disconnected or if I quit connection, and close KPPP.  
Kernel is 2.6.40.4-5.fc15.x86_64
Log in and log out is normal.  All seems well after one day of testing. Much obliged!
Regards, Liza

running 4.7.1 on gentoo.  Haven't seen this problem crop up in a while now.  Seems to be fixed.

(In reply to comment #52)
> I originally posted under comment #39 a dial up user.  This week I received
> Fedora 15, installed KDE desktop default version 4.6.2.  Did all updates and
> downloaded and installed KDE 4.7.1 as instructed at Fedora forum.  
> I am happy to say I am no longer having the CPU spiking problem if I am
> disconnected or if I quit connection, and close KPPP.  
> Kernel is 2.6.40.4-5.fc15.x86_64
> Log in and log out is normal.  All seems well after one day of testing. Much
> obliged!
> Regards, Liza

I'm not good at bug reporting, but an update.   I suspect this bug is related to ntrack 011 that is found in Pardus 2011.1 and Pardus 2011.2.  I came to this conclusion because I just noticed Fedora 15 with KDE 4.7.1 does not have ntrack installed.   I also just compiled ntrack-014.tar.gz in my Pardus 2011.2 for 65 bit installation and I am no longer getting this high CPU usage that would occur after disconnecting, waiting a few minutes and reconnecting and resolv.conf getting filled with nameservers, at that point is when kdeinit4 would spike the CPU and result with very slow response from KDE desktop apps.  
Errors in dmesg after reconnecting:
"[12922.795717] netconsole: network logging stopped, interface ppp0 unregistered"
If I ran "kdeinit4" in terminal after this CPU spiking, this is part of output:
"kdeinit4: Shutting down running client.
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
ntrack backend selected and created: ntrack-libnl1.so
kbuildsycoca4 running..."
I suspect the culprit was /usr/lib/ntrack/modules/ntrack-libnl1.so as I removed that file and the problem went away in 011.  
In version 014 after a reconnect with dial up KPPP, dmesg shows:
PPP generic driver version 2.4.2
"[  481.785071] PPP Deflate Compression module registered"
I'm still working on this as I had to compile the ntrack tar package, which didn't put the files in exactly the same places as the default installed ntrack-011, but, it is working for me.  In Pardus, it uses a different package manager so I can't install .deb or ubuntu packages in it, and have to compile them.  
Regards, Liza

Correlation isn't causation.  I've hadn't even heard of ntrack or pardus and it isn't offered as a package on my system (gentoo).  Obviously I've never installed it or had it as a result of a secondary dependance.  In any case, why would a package that is installed but not running and hasn't been started cause 100% cpu usage within kded.

The problem went away for me as well, around version 4.7.x

ntrack is not a program, it is a library that kded's networkstatus module uses. You just need to compile kde-runtime against ntrack to be susceptible to a ntrack bug. To disable ntrack you also need to recompile kde-runtime.

(In reply to comment #55)
> Correlation isn't causation.  I've hadn't even heard of ntrack or pardus and it
> isn't offered as a package on my system (gentoo).  Obviously I've never
> installed it or had it as a result of a secondary dependance.  In any case, why
> would a package that is installed but not running and hasn't been started cause
> 100% cpu usage within kded.
> 
> The problem went away for me as well, around version 4.7.x

Glad to hear it went away in version 4.7.x. whatever caused it.
For me it was ntrack in KDE4. It was difficult for me to pinpoint which is why I posted here.  I'm just glad I have.  Removing libntrack files from /usr/lib and ntracklibnl1.so from  /usr/lib/ntrack/modules worked, though a dirty way to do it.  I obviously posted my bug at the wrong place, and should have posted it here:https://bugs.launchpad.net/ntrack/+bug/755608
The good news is that this bug in ntrack is supposed to be fixed in release 0.015.  
Thank you, Lamarque Souza for the information that ntrack library, and how it is used in kde-runtime.  Much appreciated.
Liza

Thanks for the update, let's close it then.

If you are still getting issues with kded4, please add a comment or open a new bug. For more information see http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/

*** This bug has been marked as a duplicate of bug 268038 ***