.xsession-errors fills hard drive until system crashes

[Lisa Simpson]

This seems to be a very wide spread problem. I have found that occasionally deleting the .cache directory in my home folder seems to solve a lot of this. I keep having this file fill up a 750GB partition in less than 24 hours. Filling 750 GB, making me find the file, delete it, and then have to reboot to continue working is patently ridiculous. It's flatly unacceptable for a server and only marginally so for a workstation.

When I google for "xsession-errors filling hard drive", I get lots of hits from multiple linux distros, so this isn't isolated to Ubuntu or Debian. And the date range is quite extensive as well from 2005 to the just a few weeks ago. So this has been happening to a lot of people, with a lot of linux distributions, for a very long time.

I think the fundamental solution is to change how the logging for xsession-errors behaves. Given the involvement of applications from FlashPlayer to Remina to NSwrapper to WINE to the gnome desktop, I don't see fixing every single application as a viable solution. Too many users need help NOW and, frankly, this has been happening for at least 6 years, if not longer. That's just not right. So that brings the logic trail back around to fixing how the xsession-error log file is handled and how those error messages are logged.

Suggestion #1 There should be a file size limit and once that'us s reached, it starts to overwrite.

Suggestion #2 Implement the "This error repeats 147 more times" in the error log rather than logging each error.

Suggestion #3 Point the log file to /dev/null by default and let the user point it elsewhere at their own risk. This is perhaps the quickest fix and easiest to implement as it is would be a slight change to the Xsession file in /etc/X11. Change the location and add some comments explaining the possible issues along with directions on how to change it back.

[Lisa Simpson (lisa-p)]

#720833, #588036, #589275, #498911, #759299, #106667, #47381,#765437, #750701, #60448, #162976, #761074

Anyway, that's just the first 2 pages of googling "llaunchpad xsession-error fills hard drive". As I stated, it's a wide-spread long term problem. While I admire you for attempting to address every single application, it does little to nothing until we get some assistance with how the logging is handled so that things just don't crash.

[Lisa Simpson (lisa-p)]

Right now my .xsession-errors is 314 GB. GIGS!!! I'm attaching the first 1000 lines of the file. It's a wide variety of applications that are erroring for a wide variety of reasons.

NSPlugin is erroring (mentioned in one of the other bug reports) along with GLib, Unity, NM applet, compiz, gdk pixbuf, acrobat reader and too many more to list are all spewing into this file.

[Lisa Simpson (lisa-p)]

Right now my .xsession-errors is 314 GB. GIGS!!! I'm attaching the first 1000 lines of the file. It's a wide variety of applications that are erroring for a wide variety of reasons.

NSPlugin is erroring (mentioned in one of the other bug reports) along with GLib, Unity, NM applet, compiz, gdk pixbuf, acrobat reader and too many more to list are all spewing into this file.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[3vi1 (launchpad-net-eternaldusk)]

I never experienced this before today, but this morning and noticed I had lost 300+GB of space overnight. Baobab didn't give me any idea where the space had gone (it ignores dot-files?!?!), but K4DirStats led me straight to .xsession-errors. Through my own folly, I did not capture a tail of what had been generating all the output. After reboot, the only error I see being continually re-written is:

WARN 2011-11-18 08:39:40 glib <unknown>:0 Unable to fetch children: Method "Children" with signature "" on interface "org.ayatana.bamf.view" doesn't exist

That message is only written at a rate of about once a minute, though. So, it's unlikely to be the only cause unless something caused it to accelerate in frequency.

[agent 8131 (agent-8131)]

Bug #883464 and Bug #870138 appear to be duplicates.

[agent 8131 (agent-8131)]

The horribly bad thing about this bug as people have probably noticed is that trying to delete the .xsession-errors file will not recover the free space. This is due to how linux/unix handles deletions through unlink such that the space is not freed until the every process with a file handle to that file has been terminated. In the case of .xsession-errors it means the user has to log off or restart in order for that to happen. The solution I found was to open a terminal and run:

echo > ~/.xsession-errors

[agent 8131 (agent-8131)]

However, if you have tried to delete the file and do need to free the space without logging out or restarting, for example when you have open documents that need saving and there is no more free disk space this should work:

find /proc/*/fd -type l -lname '*.xsession-errors*' 2> /dev/null

this will give you a list of filenames like:
/proc/12345/fd/1
/proc/54321/fd/2

You should be able to use any filename in that list and do:
echo > /proc/12345/fd/1

Where "/proc/12345/fd/1" is replaced by one of those filenames.

[rs232 (vincenco)]

Remmina, unfortunately, may be the source of a number of my issues. It crashes occassionally, and it causes the drive to fill up with .xsession-errors like this bug states...

Too bad, because it is a great program.

[Maarten Bezemer (veger)]

I just deleted a 73GB file, as I did not have any free space left. I just quickly browsed through it and it is not just Remmina (I do not ahve it), but (almost) all running applications seem to contribute to this file.

Within an hour or two the file grew already to 400kB. It would be nice if
 * its contents were put away somewhere and stored for a week or something and then get removed...
 * less data was spawn by the applications, as currently there is too much data to properly find any problems I am afraid...

[Lisa Simpson (lisa-p)]

You system administrators out there know just how grumpy some applications can get when the disk space runs out. Indexes get out of sync and critical things can crash in ways that make them nearly impossible to recover.

I have suggested that the default configuration be changed to in four ways to stop this from happening. Neither solution is complex and I would prefer to see both implemented. Both would stop this from happening and crashing machines.

New Suggestion:
Make each application write it's own log file to /var/log (where everything else logs) instead of the individual user's home directory. Why? ONE - That will make it a LOT easier for us to figure out which applications are misbehaving and it in what ways so that the developers on other projects will start getting meaningful bug reports. TWO - I usually put /var/log on it's own partition specifically so that if something looses it mind and starts spewing, it can't chew up all the free disk space for the entire system.

___________________________
Previously Submitted:

One: Until a more permanent fix is found, the errors should simply be routed to /dev/null UNLESS the user enables the log file. The text in config file can be altered to include instructions and a lines to un-comment/comment out to change this. It should be included with appropriate warnings like "YOU MUST MONITOR YOUR FREE DISK SPACE FREQUENTLY". This is so simple that it actually requires NO change to the existing code base.

Two: The configuration file should cap the log file size at a specified limit. If Microsuck's Winbloze can do it, surely the infinitely more talented programmers here can handle that. Once the max file size is reached, it starts writing over itself.

Three: When errors do repeat - e.g. when stuff starts spewing - instead of logging each error over and over, log something like "This error repeats 147 more times" . That saves 147 error messages. Do that for each process that logs to that file and it will grow much more slowly. Again, if the Borg Collective re-re's can figure it out, I'm sure the programmers here are more than up to the challenge.

[Paul M Edwards (paul-m-edwards)]

The script at the following site works around the issue effectively.
http://matrix.z-labor.com/tmp/xsessionlogfix/

I implemented the script on my system on Nov 21st and haven't had any issues since.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[penalvch (penalvch)]

Not reproducible in Vivid. However, this is too broadly scoped, with way too many applications to be actionable by one report. If this is reproducible in a supported release, please file one bug report per application causing an issue (not slam multiple applications together) via a terminal:
ubuntu-bug PACKAGE

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[David Grossberg (davidgro)]

#14, This bug is not "an application produces too much error logging" the bug is "the system doesn't behave in a reasonable way When an application produces too much error logging"

[penalvch (penalvch)]

David Grossberg, one could extrapolate your position to every application that logs information. This viewpoint is unfortunately a cart before the horse. For example, why as a software maintainer (which viewed by all maintainers of every application, driver, etc. that this is an application issue, i.e. the log is filling up because either the sheer volume of the information, and/or the applicability of the log messages to maintaining the application) even worry about too verbose logging? Or logging things that are most important when reviewing the applicable log? Why don't all package developers have every possible thing spew out into any log they can, generating hundreds of GB/s, grinding your OS to a crawl, and giving an overwhelming amount of irrelevant information (low signal to noise ratio)? But don't worry about it, the operating system will take care of that, and people should just get used to manually intervening in log capture modifications of every possible application they have installed (~2566 installed on my instance so that's a lot of work!), but fast enough before the logging kicks in and stops their efforts due to the OS spending all its resources on just handling logs...

Long story short, file a report against the offending application and the bug in it will get addressed.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs