Ubuntu

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

Reported by mlaverdiere on 2006-09-14
146
This bug affects 26 people
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
Low
Unassigned
kdebase (Ubuntu)
Undecided
Unassigned
xinit (Ubuntu)
Dapper
High
Unassigned

Bug Description

Hi,

I'm running Kubuntu Dapper, freshly dist-upgraded, on a Compaq Presario V2610CA laptop, with no particular esoteric configuration.

In the past 2 weeks, my disk space has been saturated **TWICE**, i.e. up to 100% occ. on a 60 GB disk with 40 GB previously free, as reported by the "df -h" command (in fact app. 10 MB was still available, just enough to be able to boot/login!). The cause of these events is what seems an ever-growing .xsession-errors file in one user directory. i.e. /home/user. After a quick search on Google, I've found 2 similar reports (one concerning Dapper, the other OpenSuse):

http://www.nabble.com/X-error-log-t1364627.html

http://lists.opensuse.org/opensuse/2005-10/msg00044.html

However, I didn't find anything related to this problem on Launchpad...

It 's quite possible that something is going wrong with my system and is filling the .xsession-errors file with various reports. I did not have the chance to pinpoint what's going wrong since my only concern was to prevent my system from completely crashing. That's why I deleted the file without trying to look at its content (my system was saturated to a point that I could not receive one simple e-mail, Kmail complaining about the lack of disk space...). The only thing I know is that since 2 weeks, I use more frequently Skype and I have created a second user account for my wife to be able to manger her e-mails with Kmail and browse the Web with Konqueror a little bit. Nothing so complex or heavy...

Anyway, this report is not about what's going wrong with my system, but instead about the fact that an error-log file, like .xsession-errors, that is supposed to be useful to track problems, should not be the cause of a major critical problem like the lack of disk space! I don't know what would be a satifying solution, but in my case I've set up a script to erase this file in root and all users directory at each hour, by putting an executable file with this content in /etc/cron.hourly:

rm /home/*/.xsession-errors*
rm /root/.xsession-errors*

Thanks for your attention.

Martin Pitt (pitti) wrote :

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

Martin Pitt (pitti) wrote :

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

description: updated
description: updated
description: updated
Léa GRIS (lea-gris) wrote :

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

Matt Zimmerman (mdz) wrote :

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

Changed in xorg:
assignee: nobody → pitti
Martin Pitt (pitti) wrote :

Fix for beta, if possible.

Changed in xorg:
status: Confirmed → In Progress
assignee: nobody → pitti
importance: Untriaged → High
status: Unconfirmed → In Progress
Martin Pitt (pitti) wrote :

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@

mlaverdiere (mlaverdiere) wrote :

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?

Matt Zimmerman (mdz) wrote :

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.

Matt Zimmerman (mdz) wrote :

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

Martin Pitt (pitti) wrote :

 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

Changed in xorg:
status: In Progress → Fix Released
Martin Pitt (pitti) wrote :

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

Martin Pitt (pitti) wrote :

Dapper ships that file in xinit.

Martin Pitt (pitti) wrote :

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

Changed in xinit:
status: In Progress → Fix Committed
Matt Zimmerman (mdz) wrote :

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.

Matt Zimmerman (mdz) wrote :

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

Martin Pitt (pitti) wrote :

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

Matt Zimmerman (mdz) wrote :

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

Kees Cook (kees) on 2007-11-27
Changed in xinit:
status: Fix Committed → Triaged

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.

Christophe Giboudeaux (krop) wrote :

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

Martin Pitt (pitti) wrote :

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?

Christophe Giboudeaux (krop) wrote :

@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.

Martin Pitt (pitti) wrote :

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.

Changed in kdebase:
status: New → Invalid
Christophe Giboudeaux (krop) wrote :

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.

Changed in xinit:
assignee: pitti → nobody
milestone: dapper-updates → none
status: Triaged → Won't Fix
Bárbara Jiménez (bas-) wrote :

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)

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.

Martin Pitt (pitti) wrote :

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.

Bárbara Jiménez (bas-) wrote :

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.

Changed in xorg (Ubuntu):
status: Fix Released → In Progress

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.

Martin Pitt (pitti) wrote :

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.

affects: xorg (Ubuntu) → gdm (Ubuntu)
Changed in gdm (Ubuntu):
assignee: Martin Pitt (pitti) → nobody
importance: High → Low
milestone: ubuntu-6.10 → none
status: In Progress → Triaged
apinunt (apinunt) wrote :

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.

Jason (beatme101) wrote :

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

Jason (beatme101) wrote :

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.

gjs (frans-stekelenburg) wrote :

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.

AmenophisIII (amenophisiii) wrote :

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).

David Volm (royboyjoytoy2) wrote :

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?

mlaverdiere (mlaverdiere) wrote :

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.)

Léa GRIS (lea-gris) wrote :

/etc/X11/Xsession patch to disable error logging

mlaverdiere (mlaverdiere) wrote :

Happy 4th birthday bug report!

scm (scm) wrote :

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.

Martin Pitt (pitti) wrote :

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?

Gabriel (misc-evotex) wrote :

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

mlaverdiere (mlaverdiere) wrote :

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...)

Aleksey Vorona (voronaam) wrote :

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.

Changed in kdebase (Ubuntu):
status: Invalid → New
summary: - .xsession_errors file grows out of control & saturates disk space
+ .xsession-errors file grows out of control & saturates disk space
Thomas Hotz (thotz) on 2012-12-03
Changed in kdebase (Ubuntu):
status: New → Confirmed
Jonathan (jonfritz) wrote :

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.

Joel Whitehouse (me-t) wrote :

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?

Miguel Negrao (miguel-negrao) wrote :

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

mlaverdiere (mlaverdiere) wrote :

Happy 7th birthday bug report!

Bob Merhebi (bobmerhebi) wrote :

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.

Bob Merhebi (bobmerhebi) wrote :

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

Alkis Georgopoulos (alkisg) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.