Huge .xsession-errors

[Zorael]

As a more system-wide solution, instead of symlinking the .xsession-errors file in your home directory to /dev/null (and possibly writing a startup script to re-symlink it if something keeps recreating it as a normal text file), you could change where the log is written to in the first place in /etc/X11/Xsession. That file will be overwritten upon updates to the x11-common package, mind.

Excerpt from line ~50 or so (11.10);

# initialize variables for use by all session scripts

OPTIONFILE=/etc/X11/Xsession.options

SYSRESOURCES=/etc/X11/Xresources
USRRESOURCES=$HOME/.Xresources

SYSSESSIONDIR=/etc/X11/Xsession.d
USERXSESSION=$HOME/.xsession
USERXSESSIONRC=$HOME/.xsessionrc
ALTUSERXSESSION=$HOME/.Xsession
ERRFILE=$HOME/.xsession-errors

If you change the ERRFILE line to instead point to /dev/null, it will discard the log entirely. If you point it to a file in /tmp/ the log will be accessible there if you suddenly need it, but get deleted upon rebooting.

ERRFILE=/dev/null
# or
ERRFILE=/tmp/$USER-xsession-errors

The good news is that the behavior changes in 12.04 precise to save it thusly in /tmp/. It still logs insane amounts of errors there, but at least the file gets purged every now and then depending on your shutdown/reboot frequency.

Mine is nearly a megabyte after an update of ~7 days. Most of the entries are Gtk/Gdk/GLib warnings, Qt4 QPainter spam and X Bad{Value,Drawable,Window} errors; none of which are a whit of interest to me.

Implied by this is that the drive gets touched and written to regularly. That's inarguably insignificant to most, but if you're on a laptop (that wants to conserve power by limiting drive activity) and/or using an SSD (to which you want to limit your amount of writes anyway), you may want to consider to just take the /dev/null approach -- or mount your /tmp as tmpfs and point your log there.

[summentier]

A word of warning: Do not delete a huge .xsession-errors (or any logfile running out of bounds and filling up your diskspace, for that matter) with rm:

rm ~/.xsession-errors   # DO NOT DO THAT - file will linger on

This will not give you back any diskspace, since the file is still connected (via internal file descriptors) to the processes writing to them (like x-session). It is better to truncate the file by issuing:

truncate --size=0 ~/.xsession-errors

This will take some time for large files, but it will free up the disk space eventually. Afterwards, you'll probably want to find the culprit (knotify4 is one candidate on Kubuntu 11.10).

If you, by accident, already rm'ed the file, then there are two ways to fix this:

• Reboot your PC -- this will usually trigger a file system check and will remove the dangling inodes
• If this is not an option, follow the instructions on http://glandium.org/blog/?p=211 : you will essentially have to find out the internal file descriptor and truncate the underlying file:
  

  lsof +L1 | grep -m 1 $HOME/.xsession-errors
  
  # Truncates the internal file: replace <PID> with the first number and <FD> with
  # the second number of the output above
  truncate --size=0 /proc/<PID>/fd/<FD>

  Do not forget to find the process that is filling up your .xsession-errors afterwards!

[biocyberman]

Thanks summentier for your insights.

@All: It's nothing to be proud of, however I need to let you know: I got a 4.6TB .xsession-errors
This monster literally ate up my RAID volume.

[chitowner2]

Wow, guess I'm a piker by comparison, mine never got over 10G, but my /home is only 25G.

I gotta wonder what the heck kind of filesystem somebody has that lets .xsession-errors get >100G. Isn't this file always in /home?

Some nice tips here to constrain this disk-***** file, but it would be cool if somebody has an idea to make it scroll somehow, so that after say 1000 lines, older stuff gets deleted. That way the purpose of the file remains relatively intact w/o growing astronomically.

CT

[chitowner2]

Thanks summentier for your insights.

@All: It's nothing to be proud of, however I need to let you know: I got a 4.6TB .xsession-errors
This monster literally ate up my RAID volume.

I see you are a fan of large FS's. I have a couple LVM's ~3T and one ~5.6T, the last has an installed base of 12T available, so it's less than half full, but I get no problems with .xsession-errors on that box, and if I did, /home is only 12G.

CT

[Rosuav]

Well, I'm joining the competition with a 719GB file that would have been bigger except that the volume it was on was only 1TB. Many thanks for the info, especially on truncating after rm (which is exactly what I'd done).

Just one small issue left. I, uhh, toasted my Xsession - by attempting a 'sudo -e' to set it to log to /dev/null, while the disk was full. Is it safe to copy /etc/X11/Xsession from one Ubuntu 10.10 to another?

I think this may be urgent in that my system might not come up again if it reboots now. Hopefully I won't reboot...

[Krytarik]

I, uhh, toasted my Xsession - by attempting a 'sudo -e' to set it to log to /dev/null, while the disk was full. Is it safe to copy /etc/X11/Xsession from one Ubuntu 10.10 to another?

Yeah, sure, you can also pull the default one from here - just open the deb package with Archive Manager, for example:

http://packages.ubuntu.com/maverick-updates/x11-common

Regards.

[Rosuav]

Yeah, sure, you can also pull the default one from here - just open the deb package with Archive Manager, for example:

http://packages.ubuntu.com/maverick-updates/x11-common

Regards.

Thanks! X is such a huge thing that I can never be sure which parts are specific to my video card (etc) and which parts are safely customizeable.

Especially appreciate the fast response. Thank you!

[JigglyWiggly_]

Someone have the best solution? All of them seem kinda meh.

On 10.04 atm.

[jars99]

Mine got up to 90GB on my 128GB SSD today.
Could you use logrotate to automatically move the file once it gets over a certain size?