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.
(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
nah, the request is valid. kdebugdialog does not solve the fundamental problem.
*** Bug 215456 has been marked as a duplicate of this bug. ***
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.
Created attachment 49449 [details] .xsession-errors file from just kde login
I believe Bug 227697 is a duplicate of this bug.
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.
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.
> 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 ...
(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
(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.
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 ... ;)
> > 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?
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
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?
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).
(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.
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.
Sorry, that was a typo. ~/.xssession-errors was 58 GB. Yep.
KDM is unmaintained and not used in KDE Plasma 5. SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/