KDE Spams .xsession-errors

[Jon Skanes]

kdelibs5=4:4.4.3a-0ubuntu1~ppa1

I just noticed my .xsession-errors file is FULL of messages that would qualify as being as unimportant as LOG_NOTICE.

-rw------- 1 jon jon 146520744 2010-05-22 17:40 .xsession-errors

17:41:38 up 17 days, 1:13

That seems a bit verbose. On a production system with little disk space, such as the one I'm using now, it is a problem. On the system of a casual, computer illiterate user, it would probably grow indefinitely and become a BIG PROBLEM. It also makes tracking down errors more difficult--needles in haystacks.

Most of the messages are normal status messages from various KDE libraries and apps so picking a package means picking dozens. Don't worry, KDE. I'm not just picking on you. Firefox is another culprit.

Is there a debug level setting for a KDE session? Maybe KDE should add a syslog type service and log to a different file altogether. A syslog type service for KDE could be useful in other ways too--prepending PID, app name, and library to a log message might be useful when things really do go wrong.

.KDE-session-errors, anyone? Separating KDE and X messages seems like it might be a nice idea as well.

For your log reading enjoyment, here are a few snippets:

KDEPIM and what looks like Kopete

CLIENT: RequestPictureTask: Task::done()
CLIENT: RequestPictureTask: emitting finished
Transfer ACCEPTED by: StatusNotifierTask
Transfer ACCEPTED by: PictureNotifierTask
kdeinit4: preparing to launch /usr/lib/kde4/kio_http.so
CLIENT: Task: Task::done()
CLIENT: Task: emitting finished
CLIENT: RequestPictureTask: Task::done()
CLIENT: RequestPictureTask: emitting finished
Transfer ACCEPTED by: StatusNotifierTask
Transfer ACCEPTED by: PictureNotifierTask
kio_imap4(11206)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 80
kio_imap4(11206)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 77
kio_imap4(11206)/kio_imap IMAP4Protocol::special: IMAP4Protocol::special
kio_imap4(11534)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 80
kio_imap4(11534)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 77
kio_imap4(11534)/kio_imap IMAP4Protocol::special: IMAP4Protocol::special
CLIENT: Task: Task::done()
CLIENT: Task: emitting finished
kio_imap4(11206)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 80
kio_imap4(11206)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 77
kio_imap4(11206)/kio_imap IMAP4Protocol::special: IMAP4Protocol::special
kio_imap4(11534)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 80
kio_imap4(11534)/kio_imap IMAP4Protocol::dispatch: IMAP4::dispatch - command= 77
kio_imap4(11534)/kio_imap IMAP4Protocol::special: IMAP4Protocol::special
CLIENT: Task: Task::done()
CLIENT: Task: emitting finished

TODO Messages? Not really helpful to an end user.
kontact(3701)/kdecore (KLibrary) kde4Factory: The library "/usr/lib/kde4/kcm_korganizer.so" does not offer a qt_plugin_instance function.
kontact(3701)/kdecore (KLibrary) kde3Factory: The library "/usr/lib/kde4/kcm_korganizer.so" does not offer an "init_kcm_korganizer" function
.
kontact(3701)/kdecore (KLibrary) kde4Factory: The library "/usr/lib/kde4/kcm_korganizer.so" does not offer a qt_plugin_instance function.
kontact(3701)/kdecore (KLibrary) kde3Factory: The library "/usr/lib/kde4/kcm_korganizer.so" does not offer an "init_kcm_korganizer" function
.
kontact(3701)/kdecore (KLibrary) kde4Factory: The library "/usr/lib/kde4/kcm_korganizer.so" does not offer a qt_plugin_instance function.
kontact(3701)/kdecore (KLibrary) kde3Factory: The library "/usr/lib/kde4/kcm_korganizer.so" does not offer an "init_kcm_korganizer" function
.
kontact(3701)/kdecore (KLibrary) kde4Factory: The library "/usr/lib/kde4/kcm_korganizer.so" does not offer a qt_plugin_instance function.
kontact(3701)/kdecore (KLibrary) kde3Factory: The library "/usr/lib/kde4/kcm_korganizer.so" does not offer an "init_kcm_korganizer" function
.
And more Kopete:
CLIENT: Task: Task::done()
CLIENT: Task: emitting finished
CLIENT: LoginTask: Task::done()
CLIENT: LoginTask: emitting finished
CLIENT: ListTask: Task::done()
CLIENT: ListTask: emitting finished
CLIENT: StatusNotifierTask: Task::done()
CLIENT: StatusNotifierTask: emitting finished
CLIENT: MailNotifierTask: Task::done()
CLIENT: MailNotifierTask: emitting finished
CLIENT: MessageReceiverTask: Task::done()
CLIENT: MessageReceiverTask: emitting finished
CLIENT: PictureNotifierTask: Task::done()
CLIENT: PictureNotifierTask: emitting finished
CLIENT: WebcamTask: Task::done()
CLIENT: WebcamTask: emitting finished
CLIENT: ConferenceTask: Task::done()
CLIENT: ConferenceTask: emitting finished
CLIENT: YABTask: Task::done()
CLIENT: YABTask: emitting finished
CLIENT: FileTransferNotifierTask: Task::done()
CLIENT: FileTransferNotifierTask: emitting finished
CLIENT: YahooChatTask: Task::done()
CLIENT: YahooChatTask: emitting finished

Happy Victoria Day Weekend!
Jon

[Mrwaltercool (mrwaltercool)]

Version: (using KDE 4.1.2)
Compiler: gcc 4.2.4
OS: Linux
Installed from: Gentoo Packages

When im starting my session using KDM, KDM starts a new .xsession-errors debugging kio-slaves and other apps on this file... doing bigger and bigger.

I have an EeePC, and that should kill my SSD disk

The solution is re-directing the log file to other side (the best solution /dev/null for my eee).

For now, /usr/kde/<version>/share/config/kdm/kdmrc have the answer.

Is not a error!, Is only debug and debug! Seems a spam to .xsession-errors file.

If you can redirect it, make a GUI for change it or limit the log file, should be nice.

Thanks.

[Pino Toscano (pinotree)]

(In reply to comment #0)
> If you can redirect it, make a GUI for change it or limit the log file, should
> be nice.

kdebugdialog

[Oswald Buddenhagen (ossi-kde)]

nah, the request is valid. kdebugdialog does not solve the fundamental problem.

[Oswald Buddenhagen (ossi-kde)]

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

[Jonathan Thomas (echidnaman)]

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. While we appreciate your issue, it would be better if it was tracked at https://bugs.kde.org, so that the KDE developers can deal with this speedily and have direct communication with you as the reporter for more effective debugging.

Thanks!

[Jon Skanes (jon-skanes)]

Looks like the bug was already reported at bugs.kde.org. That being said, disabling as much as possible in kdebugdialog takes care of most of it. Does changing the defaults in the packaging to disable debug output make any sense? If so, can you reopen this?

[Wln2qp5ozl9x-gzvg-xrvasaslqcgv (wln2qp5ozl9x-gzvg-xrvasaslqcgv)]

If you link .xsession-errors to /dev/null, kdm replaces it with a regular file on you when you login.

Thus, you cannot even work around this problem. This is very bad behavior imo.

/usr/lib64/kde4/libexec/kdm_config binary references xsession-error, thus I suspect it's the culprit.

[lykwydchykyn (me-alandmoore)]

Created attachment 49449
.xsession-errors file from just kde login

[Psychonaut (psychonaut)]

I believe Bug 227697 is a duplicate of this bug.

[Wln2qp5ozl9x-gzvg-xrvasaslqcgv (wln2qp5ozl9x-gzvg-xrvasaslqcgv)]

This bug is *over 2 years old*.
Can we please get some traction on this??
I'm still having to log out and log back in every few days to zero out the .xsession-errors file.
This is really painful.

If I could simply symlink it to /dev/null and not have anything replace the symlink on me I would be *ecstatic*.

In fact, that would be my preferred solution, since there's other non-kde apps that I would rather not have filling up that file either.

[Wln2qp5ozl9x-gzvg-xrvasaslqcgv (wln2qp5ozl9x-gzvg-xrvasaslqcgv)]

I don't care if it's KDE code, or Xorg code. I've searched the code and failed to find who is doing it. If someone could at least tell me where it's happening I will be more than happy to make a patch myself. I'm at my wit's end at this point--it's interferring with my work.

[Oswald Buddenhagen (ossi-kde)]

> Can we please get some traction on this??
>
how about "no"?

you can set DisableAll=true in kdebugrc.
or you can set

kdmrc:
[X-*-Core]
ClientLogFile=/dev/null
# and delete the respective key from the [X-:0-Core] section

as you could have found out by just reading the available documentation.

there are other reports about reducing the chattiness of kdebug by default.

i interpret this report as a request to implement a proxy process which limits the number of messages that actually hit the disk irrespective of the amount of output the applications produce. gdm does this for years, and i think it may be a good idea for kdm to do it as well. otoh, they are discussing removing this function ...

[Wln2qp5ozl9x-gzvg-xrvasaslqcgv (wln2qp5ozl9x-gzvg-xrvasaslqcgv)]

(In reply to comment #9)
> > Can we please get some traction on this??
> >
> how about "no"?
>
> you can set DisableAll=true in kdebugrc.

I've done this already months ago and *it does not work*.
Doing anything with kdebugrc or kdebugdialog has *zero affect*.
Thus: It is a bug.

> or you can set
>
> kdmrc:
> [X-*-Core]
> ClientLogFile=/dev/null
> # and delete the respective key from the [X-:0-Core] section

This I have not seen mention of *anywhere*. I will try it next.

> as you could have found out by just reading the available documentation.
> there are other reports about reducing the chattiness of kdebug by default.

Please, point us to all this available documentation. None of the bug reports have mentioned this. I've scoured google and found numerous threads complaining about this--all the same--no answers, no references to documentation about it, and no resolutions.

>
> i interpret this report as a request to implement a proxy process which limits
> the number of messages that actually hit the disk irrespective of the amount of
> output the applications produce. gdm does this for years, and i think it may be
> a good idea for kdm to do it as well. otoh, they are discussing removing this
> function ...

No, I'm not asking for a proxy or anything complicated. Simply:
a) a way to symlink it to dev null and have my symlink *respected* (IOW, not forcibly replaced on me)
or
b) a way to reduce the output being generated in the firstplace--since kdebugrc obviously doesn't work

[Wln2qp5ozl9x-gzvg-xrvasaslqcgv (wln2qp5ozl9x-gzvg-xrvasaslqcgv)]

(In reply to comment #9)
>
> you can set DisableAll=true in kdebugrc.

^^^^^^ this never worked
> kdmrc:
> [X-*-Core]
> ClientLogFile=/dev/null
> # and delete the respective key from the [X-:0-Core] section

^^^^^^ THIS, however, does! Finally a viable work-a-round. Thank you very much. IOU a six-pack.

> as you could have found out by just reading the available documentation.
> there are other reports about reducing the chattiness of kdebug by default.

I have read many bug reports about this over the past two years, and none mentioned either this work-a-round, nor the documentation describing it.
That doesn't mean there isn't one out there that does, just that I've never come across it yet.

[Oswald Buddenhagen (ossi-kde)]

the most obvious approach for a kde user looking for a solution in kdm would be typing help:kdm in konqueror (i.e., opening the kdm documentation), finding a section about configuration parameters and searching for xsession-errors. i assume that you'd be successful after a few experiments.

regarding you wanting or not wanting a proxy solution: i don't care. *this* bug (unlike the many others) is assigned to kdm, and it explicitly mentions several generic approaches. if you just want help, go to an appropriate user support forum (NOT a bug tracker) instead of adding noise to other people's reports.

just saying ... ;)

[Wln2qp5ozl9x-gzvg-xrvasaslqcgv (wln2qp5ozl9x-gzvg-xrvasaslqcgv)]

> > kdmrc:
> > [X-*-Core]
> > ClientLogFile=/dev/null
> > # and delete the respective key from the [X-:0-Core] section
>
> ^^^^^^ THIS, however, does! Finally a viable work-a-round. Thank you very much.
> IOU a six-pack.

I take this back. This did not fix it.
I just discovered that it creates it's own file anyways:

/tmp/xerr-nick-:0

and fills it with the same crap.
This is even worse, because /tmp is tmpfs not on an hdd like my /home is.

Any other ideas?

[Oswald Buddenhagen (ossi-kde)]

hmm, right, after reading the code it is obvious that this couldn't have actually worked. next try would be setting ClientLogFallback=/dev/null in addition, but then the messages will just go to /var/log/kdm.log. but the good thing is, that you can actually redirect *that* to nirvana - by passing -error /dev/null on the command line. at least in theory.

as you can see, kdm tries really hard not to lose your worthy logs. now you only need to convince the apps not to create unworthy logs. good luck with that in the other reports. :-D

[Wln2qp5ozl9x-gzvg-xrvasaslqcgv (wln2qp5ozl9x-gzvg-xrvasaslqcgv)]

With that said, I change my mind.
I now think a proxy is the correct answer--because you can't do log rotation w/o it where dozens of apps are holding the fd open forever and appending.

Can't the system logger mechanism be reused here instead of creating a whole new logging mechanism?

Any ideas why kdebugdialog/kdebugrc is ignored? Or is that probably just seperate bugs in their respective, individual apps?

[Oswald Buddenhagen (ossi-kde)]

i've been pondering redirecting the collected messages to syslog - that would have the obvious advantage of using readily available rather powerful possibilities of postprocessing the logs, especially if syslog-ng (or some such) is used. that wouldn't do away with the proxy as such, though - and removing it entirely is unrealistic, as no matter how hard we try, there will still be *some* apps which log to stdout/stderr. but i think kdebug can be even centrally configured to use syslog - at least in theory.

the kdebug problem is probably a central one. but you should really explore that in the other report(s).

[Wln2qp5ozl9x-gzvg-xrvasaslqcgv (wln2qp5ozl9x-gzvg-xrvasaslqcgv)]

(In reply to comment #14)
> hmm, right, after reading the code it is obvious that this couldn't have
> actually worked. next try would be setting ClientLogFallback=/dev/null in
> addition, but then the messages will just go to /var/log/kdm.log. but the good
> thing is, that you can actually redirect *that* to nirvana - by passing -error
> /dev/null on the command line. at least in theory.

Okay, so I've done this, and so far it seems to be working. Nothing put into
.xsession-errors and no new log files created in /tmp. I've also looked in
/var/log, and there doesn't seem to be anything growing in there either. I'll just have to wait and see if I missed something.

Too bad my distro doesn't have a built-in way to pass args to kdm--I had to
edit /etc/X11/startDM.sh directly.

Quite the convoluted way to turn of logging. But, so long as it works.

[S8-kdebugs (s8-kdebugs)]

This solution worked for me, to send ~/.xsession-errors to /dev/null
http://askubuntu.com/a/94538/53508

Also, some numbers… Today I got a warning that my /home SSD was full. ~/.xssession-errors was 12 GB.

[S8-kdebugs (s8-kdebugs)]

Sorry, that was a typo. ~/.xssession-errors was 58 GB. Yep.