Version: (using KDE 4.4.2) Installed from: openSUSE RPMs KNotify outputs an awful lot of messages to ~/.xsession-errors which aren't really error messages, but rather what appears to be generic debugging info. It shouldn't do this by default. It outputs these messages even when "Disable all debug output" is checked in kdebugdialog. See also Bug 227697.
Could you provide an output similar to bug 227697 comment #7 so that it can be seen which messages from KNotify cannot be suppressed?
Created attachment 50069 [details] Sample .xsession-errors file as requested in Comment #2
Thanks for the information. There are indeed messages from KNotify, but they account only for 892 out of 12789 lines (7%). Will be fixed. The majority of messages seem to come from Akonadi, so I would suggest to report a similar bug to Akonadi developers, and link to this attachment. Additionally, many messages come from bad .desktop files for YaST and Wine detected by kbuildsycoca4. Those errors could be filed downstream. Of course the messages should not appear when debug output is disabled. As for the "CLIENT:" stuff, please report to Kopete developers.
Same problem here with KDE 4.4.5 (Debian squeeze). My ~/.xsession-errors is full of debug messages from knotify and kglobalaccel. Every use of KDE hotkeys is logged although debug output is disabled in kdebugdialog.
Could you please check if you have a [knotify] section in .kde/share/config/kdebugrc ?
Yes, I do have a [knotify] section.
I can confirm this with 4.4.5. It even logs a line for every single keypress individually during an alt-f2. Gross. The .xsession-errors-filling-up problem has gone on *way* to long--years. No viable work-a-round has surfaced either. Something still replaces a symlink to /dev/null with a regular file at login no matter what I try. I've grepped sources and cannot find who is doing it. I've commented out the part in /etc/X11/Session/XSession that creates it--no help there either. I have to log out and log back in weekly to get rid of it--in under a week it reaches nearly 2GB, and everything becomes noticeably slower.
I can also confirm this behaviout with 4.4.5 on Gentoo, what's the state on 4.5 / 4.6?
The only work-a-round I've come up w/is to edit /etc/X11/startDM.sh and change: (gentoo) ${NAME:+--name} ${NAME} ${PIDFILE:+--pidfile} ${PIDFILE} ${START_STOP_ARGS} || \ to: ${NAME:+--name} ${NAME} ${PIDFILE:+--pidfile} ${PIDFILE} ${START_STOP_ARGS} -- -error /dev/null || \ (add -- -error /dev/null) This causes *all* of kdm + spawned processes output to go to dev null. Not ideal, but it's a sledge-hammer approach that lets me work. I have not been able to test 4.5 or 4.6--I'm waiting for kdepim to get their stuff together. As it is, kmail's imap support in 4.4.5 is very flakey so I really hope they get a new, polished kdepim in 4.6.1...
FYI, I had a problem with an overly large .xsession-errors, and in my case, the culprit seems to have been an errant panel applet. I had added the LCD weather applet, which stopped displaying itself on the panel but was still checkmarked as installed when I went to add it again to the panel. This led to messages like the following, QPainter::pen: Painter not active QPainter::setPen: Painter not active QPainter::opacity: Painter not active QPainter::brush: Painter not active QPainter::pen: Painter not active QPainter::setPen: Painter not active QPainter::setOpacity: Painter not active QPainter::drawPath: Painter not active QPainter::setPen: Painter not active QPainter::setOpacity: Painter not active QPainter::setBrush: Painter not active QPainter::setPen: Painter not active QPainter::setWorldTransform: Painter not active QPainter::setWorldTransform: Painter not active QPainter::restore: Unbalanced save/restore to appear over and over. When I saved a copy of .xsession-errors before logging out, my copy was about 55 MB in size and had 1,424,475 lines in it.
QPainter warnings are directly from Qt, so they do ignore the KDE setting "disable all debug output" indeed. Something which we should work on for Qt 5... Meanwhile, if this is a LCD weather applet bug, please file a separate bug report for the LCD weather applet guys to see it and fix it.
Comment 3 says akonadi was responsible was most of the much debug output in release mode: confirmed, and fixed today.
In general, some possibility to "blacklist" certain messages (which are displayed frequently and/or without relevance to the user) a) from popping up or b) from being queued into the message list at all would be great!
Yep, this seems to be fixed today.