.xsession-errors Consumed my Hard Drive!

If you’re a Windows or Mac user please ignore. Maybe Mac users should at least read this since they use XServer, but I have it on good authority that “Macs just work” so chances are your error logs won’t chew up all available space on your hard drive.

I recently installed Android Studio, QTCreator, Sublime Text 2, and probably some other developer tools so the increased disk usage didn’t raise any red flags. In hindsight, I should have noticed that there was no way I just installed 7 GB of new software. The proverbial poop hit the fan yesterday. I attempted to use my terminal’s auto-complete feature and received an error message informing me that a new file could not be created due to low disk space. I started deleting things in order of lowest priority + easiest to find. Unfortunately, my disk kept filling up! The ~/.xsession-error file was 7.01 GB!

I’ll skip to my solution and follow it with a detailed walk through where I address some specific errors that showed up in the log file upon startup.
note: <user> should be replaced with your username on your host.

Quick Solution

$ rm ~/.xsession-errors
# nano /etc/logrotate.d/xsession

Insert:

/home/<user>/.xsession-errors
{
rotate 2
size 1M
missingok
not if empty
compress
}

Full Solution
I first checked .xsession-error to make sure there wasn’t anything in there that might help me sort out the problem. First, I attempted to open it in nano.

$ nano ~/.xsession-error

This was a mistake. I already had no disk space, now my kernel was thrashing trying to swap stuff. Even if my disk had gobs of space, I think it would take a long time to open a 7 GB file. So, I took a quick look at the first few lines of the file.

$ more ~/.xsession-error

The timestamps indicated that the first few messages were months old so I tried to look at the last few lines of the file where the useful stuff usually resides.

$ tail ~/.xsession-error

I gave up after two minutes of no response. I don’t know the implementation details of tail, but I suspect it walks through the file to find the end. In fact, I can’t think of any other way it would do it. Anyways, if you know the line numbers you want to view, you can use sed, or if you know you want the last X bytes you can use dd to copy just the last X bytes of the file. I made the assumption that any errors unrelated to disk space would continue to be generated once I solved my disk space issue, and deleted the error file.

$ rm ~/.xsession-errors

Note that rm does not delete the file, it merely deletes the inode mapping, fortunately a quick reboot solves this problem since Linux will see no mapping exists, and reclaim the space. If you’re working on a machine that shouldn’t be rebooted, you will need to delete the file by inode using find. Here is a nice article with instructions for deleting by inode.

My disk space issues resolved, at least temporarily, I checked to see if the error file had been created on boot and then took a look at its contents.

$ ls -al
$ cat ~/.xsession-errors

After the basic, non-error stuff:

Xsession: X session started for [redacted] at [redacted]
...

I noticed something about gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used. It turns out this is a result of the user (me) not having the proper privileges to perform a CAP_IPC_LOCK on memory. I used a solution by iMBeCil on crunchbang.org:

$ nano ~/.profile

and then inserted at the end:

eval `/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg`
export SSH_AUTH_SOCK
export GPG_AGENT_INFO

Any time you change something, check the effects of that change before you move on. I deleted .xsession-errors and rebooted. I opened a terminal and saw .xsession-errors had been created, so I opened it up and saw that the gkd errors went away, and as a bonus the

(clipit:2299): Gdk-CRITICAL **: IA__gdk_window_thaw_toplevel_updates_libgtk_only: assertion `private->update_and_descendants_freeze_count > 0' failed

error did not return either. I now had only non-error type stuff in .xsession-errors on startup, and it was only 445 B to boot! Here’s what it looked like:

Xsession: X session started for [redacted] at [redacted]
localuser:[redacted] being added to access control list
tint2 : nb monitor 1, nb monitor used 1, nb desktop 2
** Message: applet now removed from the notification area
** Message: applet now embedded in the notification area

Now the last thing I wanted to fix was the growth of .xsession-errors. Granted, it would take a lot of reboots to generate another 7 GB error file appending only 445 B each time, but startup is not the only operation that appends stuff to .xsession-errors. I was thinking “Why not use a cron to monitor .xsession-errors?” It turns out Linux already provides something to do this: logrotate. I created a configuration file for .xsession-errors:

# nano /etc/logrotate.d/xsession
/home/<user>/.xsession-errors
{
rotate 2
size 1M
missingok
not if empty
compress
}

This rotates two .xsession-errors files. When the current error file grows to 1 MB, logrotate compresses it, deletes the old compressed error file, and starts a new error file. Notice that I needed to be root to modify stuff in /etc/logrotate.d/.

This has worked well so far, though I’ve hardly tested the robustness of this solution. A discussion on the details of this problem and possible root-causes will follow.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s