Version: (using KDE 4.3.2) OS: Linux Installed from: Ubuntu Packages knotify4 occasionally hangs and eats CPU on my machine (Kubuntu Karmic). I haven't been able to reproduce this consistently, but I did get a backtrace: (gdb) where #0 0x00007f25d0144373 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007f25cdcb236c in g_main_context_poll (context=0x1402100, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at /build/buildd/glib2.0-2.22.2/glib/gmain.c:2904 #2 g_main_context_iterate (context=0x1402100, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at /build/buildd/glib2.0-2.22.2/glib/gmain.c:2586 #3 0x00007f25cdcb26b0 in IA__g_main_context_iteration (context=0x1402100, may_block=1) at /build/buildd/glib2.0-2.22.2/glib/gmain.c:2654 #4 0x00007f25d1b041a6 in QEventDispatcherGlib::processEvents (this=0x13d2a80, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:327 #5 0x00007f25d0dc04be in QGuiEventDispatcherGlib::processEvents (this=0x15044c0, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202 #6 0x00007f25d1ada532 in QEventLoop::processEvents (this=<value optimized out>, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at kernel/qeventloop.cpp:149 #7 0x00007f25d1ada904 in QEventLoop::exec (this=0x7fff62ab3f80, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at kernel/qeventloop.cpp:201 #8 0x00007f25d1adcab9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888 #9 0x0000000000407f8f in _start () (gdb) It's not clear this isn't just a bug in glib or Qt's usage of it.
Could you try "powertop" utility to see how many wakeups per second you get, and according to (regular) "top", how high is the CPU usage?
(Quite conveniently, I still had this process suspended in gdb; haven't figured out how to get the core dump to load symbols.) CPU usage is at 100% (on a dual-core system). I'm getting around 80 wakeups per second, with most of them coming from 21.3% (101.2) <kernel core> : neigh_periodic_timer (neigh_periodic_timer) The others seem irrelevant (mouse, wireless, etc.) except for this little blip: 0.1% ( 0.8) knotify4 : hrtimer_start_range_ns (hrtimer_wakeup) Also, interestingly, when I resumed the process, I got several screen locked/unlocked notifications, presumably queued from when knotify4 was frozen in gdb. It then displayed several pages of [New Thread 0x7f25957ef910 (LWP 21177)] and [Thread 0x7f258afe8910 (LWP 21182) exited] before resuming spinning CPU. The backtrace at this point is still the same.
I just got a hang and the same stacktrace in nspluginviewer. I'm going to guess it's a Qt or glib bug.
Reproducible on Gentoo.
reproducible for me. kde 4.4.5. kubuntu 10.4
reproducible on current kubuntu 10.10 (beta)
This has to do with running Dolphin or Konquerer as root... once you do that, this problem will occur, otherwise it'll not. I think KDE should improve handling of processes which open as root though a non-root account (e.g. now, kwrite wont open though a dolphin instance opened as root).
you mean once I do that per session or per user-account? is there any way to work this around (like e.g. fixing some file permissions)?
Per session ofcourse.
ok, but I'm very sure that the problem also came up when the only thing I did since the login was reading email and news using kontact. or is it a problem that my session gets restored after login to the state where I left it?
Apparently in my case the problem only occurs when I'm running dolphin as root.
reproducible for me. kde 4.4.5. kubuntu 10.4 the problem comes since my sound server dont run correct.
I am experiencing this problem fairly consistently upon logging out from KDE. Whenever I log out, a knotify4 process starts consuming 99% of the CPU; I have to log in via the text console and kill it. (Often there is also a kded4 process also eating 99% of the CPU, though this is probably Bug 265400.) I am using KDE 4.6.1 on openSUSE 11.3. The problem occurred after I upgraded from KDE 4.5.0 to KDE 4.6.0. Please let me know how I can troubleshoot this; I am happy to send diagnostics, backtraces, etc. if someone tells me how to gather them.
*** This bug has been confirmed by popular vote. ***
This one of the reasons why I've not ditched Gnome in favor of KDE on client machines (laptops).
I also have this on 4.6.3 with slackware64 (built from source) knotify race.. was also dumping a complaint about gstreamer to console...
My system started hitting this issue the same day I switched from Xine Phonon backend to GStreamer. Also, sometimes instead of this very excessive CPU usage I experience crashes, which makes me think that this issue might be related or even of same source as bug 273529. Right now I'm using KDE SC 4.6.4 and it's still happening (circa once a week, I think). And AFAIR I've never run Dolphin/Konqueror as root.
Umm, sorry, now I remember I switched to GStreamer a couple of weeks earlier. That day I only updated Phonon and Phonon-GStreamer to latest Git (from 4.5.0), so it may be unrelated.
Bumping version to 4.6
Using Kubuntu 11.04 with KDE 4.6.5 from ppa. Before installing from ppa today I deleted the complete .kde folder from my user home directory. Just came back after some hours to my computer and see one core of my dual core system running on 100% because of the knotify4 process. I changed to KDE from ppa because I had troubles with my system getting extremly slow and unresponsable after some time or suddenly when something (I do not know what) happened. In this case I did not see the consuming knotify4 process but the system was nearly unuseable. Now with the KDE 4.5.6 from ppa the system is not unresponsable anymore but instead one core ist used 100%.
(In reply to comment #20) > Using Kubuntu 11.04 with KDE 4.6.5 from ppa. Before installing from ppa today I > deleted the complete .kde folder from my user home directory. > > Just came back after some hours to my computer and see one core of my dual core > system running on 100% because of the knotify4 process. > > I changed to KDE from ppa because I had troubles with my system getting > extremly slow and unresponsable after some time or suddenly when something (I > do not know what) happened. In this case I did not see the consuming knotify4 > process but the system was nearly unuseable. > > Now with the KDE 4.5.6 from ppa the system is not unresponsable anymore but > instead one core ist used 100%. I hope you know the workaround.
Problem still occurs with KDE 4.7.0.
Is anyone using a sound server?
I have pulseaudio running under my login. Don't know who is starting it. Where can I see? I have under System Settings->Notifications->Player Settings = no audio output. BTW: What is a workaround you ware talking about?
The workaround I use is to put a shell script like this one in my ~/.kde4/shutdown directory: #!/bin/bash killall knotify4 (I don't have access to my own computer now so I don't remember whether you need to use "killall -9" or just "killall".)
That's a hell of a workaround! I tried turning off sound output in the notification section in system configuration. It didn't help. On Saturday 30 July 2011 16:33:48 Tristan Miller wrote: > https://bugs.kde.org/show_bug.cgi?id=216130 > > > > > > --- Comment #25 from Tristan Miller <psychonaut nothingisreal com> > 2011-07-30 16:33:48 --- The workaround I use is to put a shell script like > this one in my > ~/.kde4/shutdown directory: > > #!/bin/bash > killall knotify4 > > (I don't have access to my own computer now so I don't remember whether you > need to use "killall -9" or just "killall".)
(In reply to comment #24) > I have pulseaudio running under my login. Don't know who is starting it. Where > can I see? I have under System Settings->Notifications->Player Settings = no > audio output. > Then keep it running. That means this issues doesn't link with audio. This bug appears to be having a lot of impact on KDE usage. For starters, I've decided not to use KDE for deployed system cause of such bugs. > BTW: What is a workaround you ware talking about? killall knotify4
A work around is one thing, but this is just plain broken and a just plain ol' hack job.. What's the point of rushing releases if you ignore problems in old revisions? On Jul 30, 2011, at 9:33 AM, Tristan Miller <psychonaut@nothingisreal.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=216130 > > > > > > --- Comment #25 from Tristan Miller <psychonaut nothingisreal com> 2011-07-30 16:33:48 --- > The workaround I use is to put a shell script like this one in my > ~/.kde4/shutdown directory: > > #!/bin/bash > killall knotify4 > > (I don't have access to my own computer now so I don't remember whether you > need to use "killall -9" or just "killall".) > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
I can also reproduce this problem consistently when unmounting an external drive. Again, I'm happy to provide further information if someone tells me how.
I am using KDE-4.7.3 on Gentoo, and this one is strange: sed-notebook ~ # ps -efa H | grep usr/bin/knotify4 | wc -l 988 So knotify has 987 children? Why? What are they doing? I have konsole and firefox open at the moment, and uptime is 8:38 h. In htop knotify constantly uses ~40% CPU and memory usage (Res) is shown as 175M. (Virt is 8573M ???) btw.: Both Akonadi and Nepomuk are _not_ running at the moment. Using "killall knotify4" gets rid of the children and the main process is silent, then. Memory usage is reduced to 20M (Res) and 353M (Virt).
The problem doesn't occur for me with KDE 4.9.5.
Thanks Tristan. Closing this, because it is quite cluttered already. It also most certainly was a Phonon issue (e.g. not correctly sending signals when sounds are finished, or could not play). If you still have issues with knotify4, please try with newest Phonon version, try switching backends, etc. and report your findings in a new bug.