.xsession-errors file grows out of control & saturates disk space

Thanks for your report. This is a well-known problem, thus I removed the private flag for easier discussion.

For /var/log we have automatic log rotation, maybe we need something similar for error logs in ~, too.

The offending code is in /etc/X11/Xsession

Some updates ago, code was changed to increment .xsession-errors instead of overwrite it.

/etc/X11/Xsession line 94:
exec >>"$ERRFILE" 2>&1

Change it back to:
exec >"$ERRFILE" 2>&1

I think reverting to the previous overwrite behaviour would be a good enough choice.

This bug affect any Ubuntu/Kubuntu/Xubuntu
Offending package:
xinit

I see no reason why this data should be preserved from one session to the next; Martin, please care for it

Fix for beta, if possible.

For the record, a short discussion in #ubuntu-devel revealed that there's no unanimous solution for this; Tollef had some proposals, let's wait a bit for the discussion on ubuntu-devel@

I Just want to point out that this could not be enough to have this file reset only upon session logout/in. The problems of this file becoming huge and filling up all the disk space could still occur for users who, for whatever reason, never log out. Think of theses users (like me) who rely on hibernate/suspend on their machine and, thus, are baisicaly always working in the same session. That being said, I don't know exactly what could be a satisfying solution: partial reset when the file reachs a size limit or on a time interval basis, keeping some of the latest data?

The best we can reasonably do at present is to rotate the file on login, so that the information from the previous session is available for debugging, but the file won't grow out of control.

Users who log out rarely should still be OK; a reboot from time to time is still necessary in order to apply updates, and this file should not grow very quickly. If a program outputs too much data to this file, that's a bug which should be fixed.

Pushing to final; this is easily corrected with an update after beta

 xorg (1:7.1.1ubuntu2) edgy; urgency=low
 .
   * debian/local/Xsession: If ~/.xsession-errors is bigger than 0.5MiB,
     truncate it to the last 0.5MiB to avoid having it grow indefinitively.
     (This does not happen with gdm anyway since gdm cleans the file on login).
     Closes: LP#60448

This is the debdiff applied to edgy, should also be suitable for Dapper.

Dapper ships that file in xinit.

Debdiff for dapper-proposed

Hi Matt,

I propose to fix https://launchpad.net/bugs/60448 for dapper.

Impact: if an application goes wild and dumps large amounts of logging
        to ~/.xsession-errors, there is nothing to clean up this file
 and limit its size.

Edgy fix: http://librarian.launchpad.net/4679751/xorg.60448.debdiff
        (xorg 1:7.1.1ubuntu2, Oct 5)
 Xsession checks if the file is > 0.5 MB and if so, only keeps
 the last 0.5 MB of data.

Proposed dapper fix: http://librarian.launchpad.net/4937364/xinit.60448.diff
 Very same patch (just different package, the file has moved)

This does not affect systems using gdm, since gdm uses its own
Xsession script which completely removes the file. I tested the fix on
a clean Dapper with using xdm, for both cases (small and large file).

Thanks,

Martin

On Thu, Oct 26, 2006 at 06:03:19PM +0200, Martin Pitt wrote:
> Hi Matt,
>
> I propose to fix https://launchpad.net/bugs/60448 for dapper.
>
> Impact: if an application goes wild and dumps large amounts of logging
> to ~/.xsession-errors, there is nothing to clean up this file
> and limit its size.
>
> Edgy fix: http://librarian.launchpad.net/4679751/xorg.60448.debdiff
> (xorg 1:7.1.1ubuntu2, Oct 5)
> Xsession checks if the file is > 0.5 MB and if so, only keeps
> the last 0.5 MB of data.
>
> Proposed dapper fix: http://librarian.launchpad.net/4937364/xinit.60448.diff
> Very same patch (just different package, the file has moved)
>
> This does not affect systems using gdm, since gdm uses its own
> Xsession script which completely removes the file. I tested the fix on
> a clean Dapper with using xdm, for both cases (small and large file).

Wouldn't it be simpler and cleaner to rotate the file to .old or such,
rather than attempting to rotate the data within the file?

--
 - mdz

Why not create a logrotate config file such as /etc/logrotate.d/xsession_errors with the following configuration:

"/home/*/.xsession_errors"
{
  rotate 1
  size 500k
  copytruncate
  missingok
  compress
}

It will check the file size daily and create one compressed copy whenever the file exceeds 500k, then remove the oldest copy and truncate .xsession_errors. to zero size.

I mean, why reinventing the wheel when we already have such a tool like logrotate.

On Tue, Oct 31, 2006 at 07:05:15PM -0000, manu wrote:
> Why not create a logrotate config file such as
> /etc/logrotate.d/xsession_errors with the following configuration:
>
> "/home/*/.xsession_errors"
> {
> rotate 1
> size 500k
> copytruncate
> missingok
> compress
> }
>
> It will check the file size daily and create one compressed copy
> whenever the file exceeds 500k, then remove the oldest copy and truncate
> .xsession_errors. to zero size.
>
> I mean, why reinventing the wheel when we already have such a tool like
> logrotate.

logrotate is designed for rotating system logs; it is not appropriate for it
to attempt to traverse user home directories. Likely problems:

- Security vulnerabilities
- NFS-mounted home directories
- Huge numbers of home directories

etc.

--
 - mdz

Hi,

Matt Zimmerman [2006-10-31 10:30 -0800]:
> Wouldn't it be simpler and cleaner to rotate the file to .old or such,
> rather than attempting to rotate the data within the file?

Neither Tollef nor I liked the .old idea, home directories are already
cluttered enough; and if the file already exists, we cannot really
decide whether the user copied it there or whether we can overwrite
it. OTOH Tollef didn't like to have it completely purged on session
start (what gdm does), so we agreed to this compromise.

On Wed, Nov 01, 2006 at 08:41:29AM +0100, Martin Pitt wrote:
> Hi,
>
> Matt Zimmerman [2006-10-31 10:30 -0800]:
> > Wouldn't it be simpler and cleaner to rotate the file to .old or such,
> > rather than attempting to rotate the data within the file?
>
> Neither Tollef nor I liked the .old idea, home directories are already
> cluttered enough; and if the file already exists, we cannot really
> decide whether the user copied it there or whether we can overwrite
> it. OTOH Tollef didn't like to have it completely purged on session
> start (what gdm does), so we agreed to this compromise.

There's plenty of precedent for rotating files this way in home directories,
using both ~ and .old. Simplicity and robustness are much more important
than an extra (hidden) file in the user's home directory. If the user
copied it to such a name, it was very likely for the same reason that we
would do so, and very unlikely that it was intended to preserve it forever.

--
 - mdz

Hi Matt,

Matt Zimmerman [2006-10-31 23:51 -0800]:
> There's plenty of precedent for rotating files this way in home directories,
> using both ~ and .old. Simplicity and robustness are much more important
> than an extra (hidden) file in the user's home directory. If the user
> copied it to such a name, it was very likely for the same reason that we
> would do so, and very unlikely that it was intended to preserve it forever.

OK, if you really want me to, I do the dapper fix in that way.
However, we do it differently in edgy, and preserving old log files
even when they are huge aggravates the actual problem (i. e. it takes
two logins instead of one to actually get rid of huge logs).

Martin

What other distributions do about this? I cannot believe that we are the only ones having this problem.

Hi Matt,

Matt Zimmerman [2006-11-01 7:05 -0800]:
> We should certainly do it the same way in both dapper and edgy.

So, does that mean you bless the currently proposed patch, or shall we
change the behaviour in Edgy, too?

Thanks, Martin

On Fri, Nov 03, 2006 at 08:46:39AM +0100, Martin Pitt wrote:
> Hi Matt,
>
> Matt Zimmerman [2006-11-01 7:05 -0800]:
> > We should certainly do it the same way in both dapper and edgy.
>
> So, does that mean you bless the currently proposed patch, or shall we
> change the behaviour in Edgy, too?

I prefer that it be rotated by renaming in both instances, thanks.

--
 - mdz

I'm sorry, but is this bug supposed to be resolved ?

I've just lost some of my applications settings because .xsession-errors got monstruously big (more than 4 Gb).

I'm using Hardy Heron and kdm as a login manager (if this detail has an importance)

@krop

Is it growing again? What are the contents? If it is growing again over 0.5 MB, just reopen the bug.

It's mostly kde4 apps messages, but the content is not very important IMO :-)

I just checked that the Xsession script code to truncate .xsession-errors is still existant in Hardy. Apparently the script is not used any more by KDE 4? Seems KDE4 needs to get its own fix for handing the ~/.xsession-errors file then?

@Martin : I'm not using the KDE4 packages. Just using the kdm-kde3 one as login manager.

So, the "truncate ERRFILE" part is present in /etc/X11/Xsession.

However, for what I understand, this script is only read once when users are opening their session.

There is no control of .xsession-errors' size _while_ the session is running.

Ah, thanks for clarifying. Indeed, there is nothing that could clean up ~/.xsession-errors while a session is running.

Do you see a lot of recurring lines/patterns in your current file? One issue is that this file shouldn't grow so large in the first place. Sometimes programs go wild and spam the file with thousands of identical lines repeatedly. Those should definitively be fixed.

Closing kdebase task again.

Since I'm not using KDE4 packages, what I notice may be irrelevant.
I'll just mention Nepomuk being way too verbose when associated with Strigi for desktop search. If not properly set up, xsession-errors may be endlessly parsed.

@Martin,

Can't we add a filter before redirecting to the error file? Instead of:

exec >>"$ERRFILE" 2>&1

we could have

exec | /usr/bin/fifo "2048" "$ERRFILE" 2>&1

fifo is a simple program (a script or even C program) that reads from stdin and writes to an output file while the file size is under a limit of a given number of KB, then it deletes full lines from the start of the file until the file is under the limit again, so it can keep writing. It is pointless to have a xsession-error of more than 2MB (even 1MB seems already too much).

manu [2008-04-21 11:21 -0000]:
> exec | /usr/bin/fifo "2048" "$ERRFILE" 2>&1

That would be very inefficient, for every newly logged line you need
to entirely rewrite the file. That's a lot of I/O churn.

I don't consider it a good idea to change this in dapper now.

I don't think this is fixed at all: for me, .xsession-errors file has turned into a 279GB monster!
Karmic Koala, AMD64

Bárbara Jiménez [2009-10-21 11:40 -0000]:
> I don't think this is fixed at all: for me, .xsession-errors file
> has turned into a 279GB monster! Karmic Koala, AMD64

Which desktop environment are you using? It's obviously not GNOME?

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Yes, it is GNOME. Why not?

Bárbara Jiménez [2009-10-21 12:52 -0000]:
> Yes, it is GNOME. Why not?

Because with GNOME ~/.xsession-errors is cleaned on every session
startup. So either that's broken for you for some reason, or you just
have run your session for a very long time, or there is some
particular process which spews a lot of messages into it.

Can you please copy it aside (copy it to ~/xsession-errors.old),
log out, back in, and check how big ~/.xsession-errors is? Did it get
appended on or emptied?

If it got emptied, how long have you run your previous session since
the last login from gdm? (suspending/hibernating continues an existing
session)

If the last session isn't that old yet (like only a day old), is there
something in ~/.xsession-errors which got repeated over and over?

Thanks, Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt escribió:
> Can you please copy it aside (copy it to ~/xsession-errors.old),
> log out, back in, and check how big ~/.xsession-errors is? Did it get
> appended on or emptied?
>
Looks like the file has been emptied: it was 90 KiB (in 4 hours) and the
new one is 9,6 KiB. The content is also different.
> If it got emptied, how long have you run your previous session since
> the last login from gdm? (suspending/hibernating continues an existing
> session)
>
The session that generated the huge file lasted about 2 or 3 days. I
deleted that one (I needed space!) and started a new session.
> If the last session isn't that old yet (like only a day old), is there
> something in ~/.xsession-errors which got repeated over and over?
>
It seems that I get a lot of errors related to chromium-browser:

[7431:7433:15691525357:ERROR:/build/buildd/chromium-browser-4.0.223.6~svn20091020r29510/build-tree/src/base/file_util_posix.cc(654)]
Couldn't stat
/home/bas/.mozilla/plugins/npcxoffice-e1fb6b4d-f87c-46a0-a2ec-85f2513f61ae.linux.NPSWF32.5664.so:
No existe el fichero ó directorio
[7431:7433:15691525478:ERROR:/build/buildd/chromium-browser-4.0.223.6~svn20091020r29510/build-tree/src/base/file_util_posix.cc(654)]
Couldn't stat
/home/bas/.mozilla/plugins/npcxoffice-6f4a9df6-03d7-44b0-813e-97b8545b5740.linux.NPInfotl.7999.so:
No existe el fichero ó directorio
................

And also:

fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT
3600000
fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT
3600000
fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT
3600000
.................

Thank you.

Bárbara Jiménez [2009-10-21 16:46 -0000]:
> It seems that I get a lot of errors related to chromium-browser:

Thanks for testing. So this should be fixed in chromium then.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

I'm the original reporter for this bug, more than 3 years ago, on Dapper. I don't want to criticize anyone, but it amazes me to see that this bug is still causing problem on Karmic...

Here's what I think:

It's OK to point out that Babara's problem was caused by a buggy Chromium installation. But still, a Ubuntu installation should not allow any buggy program to cause a disk saturation with an out of control growing .xsession_errors file... It has to be some better ways to deal with error logs caused by a faulty program, no?

Also, we should keep in mind that emptying this file on session startup may not be sufficient. For those of us who use suspend (sleep) on laptop, a session may last forever (well, almost...), so the file will never be cleaned up on time to prevent serious problems when a buggy program starts to create error logs.

Only tested in my computer, so use it at your own risk. Open a console and write:

cd ~
rm -f .xsession-errors
ln -s /dev/null .xsession-errors

Now .xsession-errors will always be zero size. If you ever need to check the errors or revert this, you do 'rm -f .xsession-errors" and it will be created in the next reboot.

mlaverdiere [2009-10-22 11:08 -0000]:
> I'm the original reporter for this bug, more than 3 years ago, on
> Dapper. I don't want to criticize anyone, but it amazes me to see that
> this bug is still causing problem on Karmic...

It's a totally different root cause, though. Back then, the problem
was that the login managers never truncated ~/.xsession-errors. They
have done this for years now. But that doesn't help if programs spam
the log within a session.

> It's OK to point out that Babara's problem was caused by a buggy
> Chromium installation. But still, a Ubuntu installation should not
> allow any buggy program to cause a disk saturation with an out of
> control growing .xsession_errors file...

That's true, but not quite easy to achieve.

manu escribió:
> Only tested in my computer, so use it at your own risk. Open a console
> and write:
>
> cd ~
> rm -f .xsession-errors
> ln -s /dev/null .xsession-errors

Thank you, manu, I will try that.

Here's a suggestion (keeping in mind that I'm not a developer, programmer or anything alike - I'm just an "advanced user"): What about a cron job that would run a script a regular interval (let's say each hour), and delete any oldest content of the .xsession-errors file that exceeds any reasonable amount of files pace (out of nowhere, I would say 10MB - that's already a pretty heavy log!).

Again, my reasoning is that I prefer to have a functional and healthy system with a partial error-log file than a complete error-log file that I won't be able to access because it has rendered the system unusable...

Of course, there may some more elegant solution... Anyway, thanks for helping.

It's gdm/kdm/other DM open this log file and keep it open; so they'd need to watch it and truncate it regularly.

It appears that the .xsession-errors file creates anew after each reboot, moving the previous content to .xsession-errors.old and an enormous size file can be eliminated by rebooting twice, but what is causing the file to grow needs to be determined and fixed otherwise the problem recurs. I think my problem has been found to be playing video files and the driver for my video card, ATI Radeon Mobility M6 LY, is not properly supported under Ubuntu 9.10, although it was previously under 9.04 and earlier.

I can't find any text editor that can open a > 1 GB text file so I have no idea what's causing it to expand that much, clearly the only way to solve the expanding .xsession_errors is to cap it at a certain file size. Having an option to disable it entirely would be nice too.

The file grows to 10 GB (the size of all of my free space on the partition) in less than a day on my system, although it doesn't happen every day.

#47

Jason, try:

tail --lines=20 ~/.xsession-errors

If you don't experience any other problems with X windows, just disable it, see comment #41

err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Input/output error

It seems that this error is filling it up at a rate over 20 MB/sec while I type this. Thanks for the command, manu, very helpful.

I just tried disabling the file per those instructions making a link to /dev/null. .xsession-errors is now 0 bytes and seems to be a link, but I'm still slowly losing free space.

I need to restart before I start losing config files again, so I won't be able to search for the cause right now. I tried waiting for disk usage analyzer to look through my drives but it takes too long on the two 500 GB drives. Whatever other file is growing, it's clear it was happening at the same time as .xsession-errors.

Stumbled upon this thread b/o system filling up to 100% slowly without clear reason.
I second the last report by jason, similar issue, the .xsession-errors was huge, removed it.
Amazing this issue still exists (or reoccurs)

yet slowly but surely the filesytem fills up with a MB per 1-3 minutes.

this is still an annoying problem in lucid with gnome while running buggy/verbose software. the file needs to be truncated in realtime and should be disabled or put on a ramdisk for ssd users imho. this potentially breaks the users' hardware in the long run without anything being really broken (most of xerrors is spam anyway)!
(in my case it was npviewer aka §"$%""!%-flash).

Ive got ubuntu lucid and gnome, I don't log off, I'm running simple lampp server. This morning I woke up to find that I had 2GB space left because I had a massive 650GB log file in my hard drive. I deleted the file manually, but should I just disable logging until this is fixed?

Is there someone from the Ubuntu Security Team /Ubuntu Review Team listening to this report?

This bug, as I've experienced it at first (I'm the initial reporter) and as it is experienced by other reporters here, can clearly crash down a system, so it's not just some ordinary "risk less" bug. I've reported this almost 4 years ago and at first, it was flagged as "high importance" but since then, it has been reflagged as "low importance" ans left unresolved even if there are regular reports showing that it is still a serious threat ...

What does it take to get some attention on this bug?

Thanks.

(Please note that, for the time being, I'm not personally affected by this bug, so my "activism" is only the result of an "irrepressible" desire to have my preferred Linux distribution do the right thing with a longstanding bugs representing a serious security/stability risk.)

/etc/X11/Xsession patch to disable error logging

Happy 4th birthday bug report!

Attached is a patch to gdm-session-worker to at least allow .xsession-errors to be a symbolic link, so it can be manually moved elsewhere.

scm, as this bug has a much broader scope, I created bug 771661 for the "allow symlinks" part of this. Thanks!

I just came across this bug report after finally tracking down my own disk space issues to .xsession-errors.old. The file had grown to over 13 GB!

Obviously, most users are not affected by this bug, so it seems to be triggered by excessive error reporting somewhere else. In my case, the most common error is this, repeated over and over and over:

(gnome-power-manager:2073): Gtk-WARNING **: A floating object was finalized. This means that someone
called g_object_unref() on an object that had only a floating
reference; the initial floating reference is not owned by anyone
and must be removed with g_object_ref_sink().

I understand that's not really helpful for tracking down the source of the error, but the redundancy of the errors got me thinking. At least on my system (10.10, 64-bit), old errors are occasionally moved from .xsession-errors to .xsession-errors.old, and the latter file is the one that soaks up all the disk space. Others have suggested modifying the code to prune the logs occasionally. That should eliminate the problem entirely, but it hasn't been done. If there's a reason that cannot be done, maybe the error redundancy could be exploited using compression?

I have this on a fresh install of 11.04, in about 5 days without rebooting, logging-out/in or suspending my .xsession-errors fills up to about 140 GB. I use this system for work so this is really annoying, rebooting or logging out/in is a hassle because I have to re-setup my environment (I can't automate this). I checked the /etc/X11/Xsession and it is supposed to be doing the rotation (which it doesn't seem to be doing in reality).

Cheers

I'm a bit late, but anyway, happy 5th birthday bug report!

(Last 2 recent messages show that this bug is still a major security issue...)

I have this bug with the freeRDP issue:
http://sourceforge.net/tracker/index.php?func=detail&aid=3315749&group_id=278330&atid=1181674

Patched /etc/X11/Xsession to log errors to /dev/null.

Why was this marked invalid? According to comment #45, it's the desktop manager's responsibility to truncate .xsession-errors. If so, it's a kdm bug, since I still see the same problem under KDE.

I'm also affected by this issue some 2315 days after it was originally reported. My home server is running Ubuntu 12.04 LTS, and contains a 500GB system partition that was entirely filled by .xsession-errors in under 48 hours.

In my case, the file is full of the message "Authentication deferred - ignoring client message" which seems to indicate some issue with vino-server, but that's a separate point altogether.

If a file is growing at a rate of 8GB/h, there is surely something seriously wrong with the host system! I only managed to find this issue because my disk space kept evaporating and I'm an advanced enough user to find a massive hidden file and then go looking for more information about said file. As of this moment, I'm still not even sure what to do to solve the actual issue that is causing the file to grow.

The real purpose of this post is to attempt to chastise somebody into fixing this stupid bug once and for all. I understand the problem that this log file is attempting to solve, but there must be a better way of going about it.

Why not rotate the file out after a reasonable size has been reached... say 100MB or so? If the file is already being cleared on every session restart, then the developers have demonstrated that they don't care too much about what's in it, as most folks restart their machines daily. If a file contains more than 1MB of the same log message over and over and over again, then as much information has been reported to the user as is available about that particular error. Another 450-some-odd gigs isn't going to help the situation, and may cause stability and security problems to boot.

Better yet, if the file is getting this much traffic, why not inform the user that there may be a problem with his/her system? Again, I wouldn't be complaining on this very forum if I weren't an advanced user. I've installed Ubuntu on my mother in law's machine, and I can assure you that she wouldn't have any idea what to do if her laptop started complaining that it was low on disk space. If the gods are smiling, she might think to empty the recycle bin.

Honestly guys, let's try and fix this one. It's getting ridiculous at this point.

This bug locked me out of a server running Ubuntu 12.04 Desktop 64-bit with the latest updates as of 3/28/2013. I only access this server via its freenx/ssh daemons. I discovered the insane disk usage by .xsession-errors.old after my nx client couldn't get past "Authenticated" during the login process. Logging in via the console, I was able to reboot the system twice, which cleared the file. This bug is still in the wild, performing DOS attacks on unsuspecting sysadmins.

I don't want to lose the log file in case it's needed for debugging. But can we please keep it from getting this big in the future?

This still happens on 13.04 !! Can't we limit the size of .xsession-errors from growing beyond a certain fixed size ?

Happy 7th birthday bug report!

I found this bug while searching about this file.
I had 24 GB of free space in /home until suddenly I was warned that I only have <1GB left!

I am currently making a copy of the file on an external disk (if needed by you?) and afterwards I'll delete the one in my home.

As a matter of fact, having read the above comments, I decided to opt out of making a copy of the file.

Btw, I am running Ubuntu 12.04.3

Xsession or xinit should install a filter on stdout/stderr that checks every line in the output, so that if the same line is written repeatedly, they'd display something like:

<$REPEATED_ERROR_MESSAGE_PRODUCED_BY_WHATEVER_APPLICATION>
$date - Xsession: last message repeated 1.000.000 times

Pulseaudio does something similar, producing entries like this in syslog:
Nov 9 10:35:42 alkisg pulseaudio[2031]: last message repeated 7000 times

I became affected by this bug after passing control to /etc/X11/Xsession from ~/.xinitrc with Slim as login manager, since I barely log out/reboot I started looking for a way to fix it and I found a quite clean way to do it in this post:

http://<email address hidden>/msg14226.html

By creating a /etc/Xsession.d/05noerrfile file.

I think it should be considered to be the default behavior.

I'm running Ubuntu 12.04, slim, i3.

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

I'm 2 days late, but anyway, I sincerely wish you an happy 8th birthday bug report!

I also stumbled across this thread as well when my .xsession-errors file filled up my harddrive completely, twice...

Just like to shed some extra light on this.

First of all, I'm running a CentOS installation atm, and am also bitten. So this is not a distribution or desktop specific error.

There are several posts telling people to delete the file, or have it automatically be rotated. However, that will not work unless you also log out, as there are many processes keeping the file open for future error messages and the OS will not free the space until all processes that hold the file have closed it. This might explain some posts saying that the disk space keeps getting eaten up even after deleting the file.

As we will probably never be able to trust all programmers to handle error output in a suitable manner, we need a common solution that would also handle misbehaving programs. As someone else mentioned, syslog/messages already handles this with
.... last message repeated X times
Every program writing to syslog do that through a common API. 'someone' with influence need to come up with a similar solution and force every program to use that for user/desktop error reports as well. That is the only long term solution.

Anyway, here are the possible solutions as of now:
1. Log out and in periodically to prevent the file to grow too large. (As I seldom do that, and the systems I run never do, that is not a suitable solution for me....)
2. Have messages normally going to .xsession-errors go to /dev/null instead. This can be done by altering /etc/X11/xinit/Xsession (at least on my system). Of course, this removes the possibility of ever discovering there is a problem, but at least I can keep my hard drive to myself....
3. Wait for someone to make a proper API and have all programs use that for error output....

Someone already did, and it is called journald: http://0pointer.net/blog/projects/journalctl.html
Recent versions of gdm, kdm and dbus already use the journald by default to replace .xsession-errors, and thus avoid all these problems. I guess we only have to wait for Ubuntu to catch up to Fedora and OpenSuse. (I don't know about CentOS, but it unavoidable that journald will be the default there eventually)

Amazing, wonder how that slipped my radar...

Anyway, I notice it is included in RHEL/CentOS 7, but not in 6.

Hopefully we won't see any happy 10th birthday comment from mlaverdiere :/

I confirm manuellopezibanez's stagement: On my Fedora 21 system, journald is used and there is no .xsession-errors file, like those I still found on other Ubuntu machines around the house.

I'm just wondering if there are still legacy apps (or apps not so well integrated with gdm/kdm/dbus), that may try to drop output in a .xsession-errors file...

Anyway, I will be more than happy to close this report when Ubuntu catch up on journald... and then, to stop posting birthday comments on Sept. 14 of each year ;-)

Is it time to close this report (i.e. is journald finally integrated in Ubuntu, replacing .xsession-error)?

If not, then happy 9th birthday bug report!

I just stumbled across this bug report, while searching for xsession-errors. There are currently 3330 bugs involving xsession-errors:

https://launchpad.net/+search?field.text=xession-errors

I wonder how its possible to even find any useful information in such an amount of open bugs. Since Ubuntu is moving to the systemd journal its probably best to close most of those bugs?

For the record, I'm having this problem, even if my file won't go too big to crash my system, because I logout everyday.

I'm using 16.04 (LTS) with 'lightdm' and 'awesome' window manager, so no gdm here.

For me, it seems it's firefox plugin container of adobe's flashplayer which is dropping tons af Gtk errors inside that file (but flash works nicely) (we're talking something like 1 megabyte per minute).

Anyway, I tried to do some dirty logrotate, but it doesn't work. Even 'copytruncate' won't do the job (copy works but not the truncate part...). So if anyone ends up here, don't try that.

Since this problem remains active in Kubuntu 20.04.1, where is @mlaverdiere to wish an happy 14th birthday bug report!?

Please tell us what the messages are still filling the log in Kubuntu 20.04.1

There are a lot of random messages. However, in my case I guess the most offensive ones come from Ktorrent.

That's a bug/feature in Ktorrent and maybe other apps. Please report your issues to the developers of Ktorrent and any other affected apps.

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