knotify4 generating many interrupts

[Rafal Kwasny]

Powertop reports knotify4 generating many interrupts:

  18.4% ( 92.2) knotify4 : schedule_timeout (process_timeout)

after attaching to the process with strace one can see:

stat("/home/mag/.kde4/share/config/kwin.notifyrc", {st_mode=S_IFREG|0600, st_size=439, ...}) = 0
lseek(24, 439, SEEK_SET) = 439
stat("/home/mag/.kde4/share/config/kwin.notifyrc", {st_mode=S_IFREG|0600, st_size=439, ...}) = 0
lseek(24, 439, SEEK_SET) = 439
stat("/home/mag/.kde4/share/config/kwin.notifyrc", {st_mode=S_IFREG|0600, st_size=439, ...}) = 0
close(24) = 0

on every mouse move,every click etc

This is unnecessary utilizing battery on laptop systems

[Brian Harkness (maestro-bwh)]

Not sure if this is related, but it crashes on exit and prevents an exit. If I confirm the crash, kde4 will continue to shut down. Oddly, if I merely log off, there is no message that I can see. I started a thread in kubuntu forums and it has already gotten replies that the issue is happening with them.

[Alessandro Ghersi (alessandro-ghersi)]

I confirm this bug in kde 4.0.4. I add moreover, Knotify4 crash occasionally when shutdown

[djtm (djtm)]

I can confirm the bug under 4.1 beta 1 and linux 2.6.25.

And yes, it makes kde4 a no-go for laptops on battery.

[djtm (djtm)]

I see endless sequences of
[pid 3056] 18:00:13 select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) <0.010012>
[pid 3056] 18:00:13 select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) <0.009705>
[pid 3056] 18:00:13 select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) <0.009940>
[pid 3056] 18:00:13 select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) <0.009945>
[pid 3056] 18:00:13 select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) <0.010975>
To me it looks a lot like it's just generating endless timeout loops.

[djtm (djtm)]

It seems disabling notifications is a temporary fix:
http://bugs.kde.org/show_bug.cgi?id=151546#c4

The bug was above said to have been passed to xine
http://sourceforge.net/tracker/index.php?func=detail&aid=1833274&group_id=9655&atid=109655
it ended up "private", though. The xine mailinglist does not show any sign of it:
http://sourceforge.net/search/?ml_name=xine-devel&type_of_search=mlists&group_id=9655&words=powertop

Suse seems to have fixed it for 4.0.x, but not for 4.x (4.1 beta)
https://bugzilla.novell.com/show_bug.cgi?id=373181

The most current kde bugreport seems to be
http://bugs.kde.org/show_bug.cgi?id=156215

[djtm (djtm)]

This bug is fixed in KDE 4.0.83.

[djtm (djtm)]

Could someone please confirm it's fixed?

[Giorgos Kylafas (gekylafas)]

It is still there in KDE 4.1.0

[Harald Sitter (apachelogger)]

Fix applied in trunk - backport for 4.1 (Intrepid) necessary.

[djtm (djtm)]

The developer said the part was rewritten
and a backport will most probably not happen.

It should really be fixed in 4.2.0, though.

[Stefan Fleiter (stefan-fleiter)]

There is a fix for this from Matthias Kretz at http://www.kde-apps.org/content/show.php/Phonon+Xine+TNG?content=84411.

This bug is worth fixing especially for notebook users as it reduces battery time.

If the bugfix seems too dangerous at this time of release there should at least be no dependency to
phono-backend-xine from kdebase-runtime and kubuntu-desktop.

With phonon-backend-gstreamer the problem is not there.
But kdebase-runtime lists phonon-backend-xine explicitly before phonon-backend
and kubuntu-desktop directly depends on phonon-backend-xine directly.
If these two dependencies where fixed the problem would vanish for new installations.

Is there a special reason why phonon-backend-xine is preferred to phonon-backend-gstreamer?

[Harald Sitter (apachelogger)]

Due to quality assurance reasons we can't include the necessary changes. They are part of a greater code rewrite in phonon-xine which can, due to the very nature of untested software, cause a lot of unwanted side effects (crashes/bugs). This is also the reason the changes didn't get backported to KDE 4.1.

As for gstreamer: last I checked the backend was not working and doesn't (again quality wise) not messure up to the xine backend. Another reason is that we ship Amarok 1 by default, which uses xine, so in order to stay consistent and save disk/CD space the xine-backend is the way to go.

[Giorgos Kylafas (gekylafas)]

I just wanted to bring to notice the workaround mentioned at http://bugs.kde.org/show_bug.cgi?id=156215#c23, which works for me.

[Jonathan Thomas (echidnaman)]

The fix has been committed upstream, so marking as such.
The fix will be included in KDE 4.2 and Kubuntu 9.04.

[Jonathan Thomas (echidnaman)]

The fix has been released to Jaunty.

[Jonathan Thomas (echidnaman)]

The bug got reopened upstream.

[Luis Silva (lacsilva)]

I'm now using kubuntu jaunty and I get a solid 3 wakeups/second from knotify4 with or without activity.

[Stefan Fleiter (stefan-fleiter)]

I also get 3 wakeups per second and thats much better but still not tolerable for doing exactly nothing.

[Andrew Mason (slackmase2)]

Yeh I'm running karmic and it still generates 3-8 wake ups even when I'm not doing anything.

[Jonathan Thomas (echidnaman)]

Should be fixed in KDE 4.3.4.

[Matthew Gates (matthew-porpoisehead)]

I am having this with Natty, when I run awesome window manager. I use some KDE apps (konsole, kphotoalbum, ktorrent). Sometimes I find several instances of knotify running, each sitting on the CPU pretty hard. Difficult to know when they start - first thing I know is when I notice my CPU fan running loudly.

Natty was a fresh install from CD (beta CD image, and upgraded with aptitude after the official release).

[Nick Shaforostoff (shafff)]

i have this issue in 11.04 as well ;(