9

Is there some way to limit size of .xsession-errors.?

I'm getting huge numbers of one particular debug information messages and it has blown the file size up to 2.8 GB (over many months). The message accounts for 95% of all the lines in .xsession-errors.

I think I know which app it is, and I'll have to look into that separately, but for now I'd like to know if there is a setting to prevent open-ended growth of the log..

The log is currently split over 2 files.. (0.8 GB and 2.0 GB)

UPDATE:
After applying RobinJ's suggestion of logrotate (which does keep the file size down), I noticed that after I manually deleted the 2.0 GB file .xsession-errors.old, it has re-appeared (size = 0) ...

This means that something other than logrotate is managing this log file, in which case it seems that this other app may be able to manage the log's size limit, etc. and would be more appropriate..

What is this program?

===========
Post answer edit: My update actually changed the tone of the original question and Mark Russell has answered this second point very well.... RobinJ has answered my original question as per the title.. thanks to both..

1
  • 1
    FYI - if you haven't found it already, the culprit could be Spotify beta.
    – user52329
    Mar 27, 2012 at 19:42

4 Answers 4

5

logrotate should be able to do that.

3
  • Thanks RobinJ. logrotate got it working... For other readers of this comment, I found the following link very useful in explaining the details of logrotate: Understanding logrotate on Ubuntu articles.slicehost.com/2010/6/30/…
    – Peter.O
    May 31, 2011 at 23:55
  • Robin... I've added new info to my question, so I've put your answer "on hold" and see what pans out.
    – Peter.O
    Jun 1, 2011 at 1:30
  • There was a command that could show you what program is trying to access wich file, if I'm not mistaken. I'll take a look at it for you when I'm at home.
    – RobinJ
    Jun 1, 2011 at 6:33
3

fred. .xsession-errors is cleared on every restart of your X session. Actually, it's renamed to .xsession-errors.old and a new .xsession-errors is created upon X login. So if you have a massive .xsession-errors log, two logout/logins would clear it out. So will manually deleting it, my point is that given the regularity of kernel security updates, it's not expected that sessions will last for months.

Your description (the file growing so large over the course of months) suggests that you haven't rebooted during this period. If this is not the case, i.e., you have restarted the system and yet the file was never rotated, please post more information, starting with: what release of Ubuntu are you using? Are you running GNOME or KDE or another desktop environment?

As for the file re-appearing automatically, there is no separate application managing the log file. The reason the file is recreated is because of how redirection works. E.g. the command echo stuff >> /var/log/stuff.log will work whether or not /var/log/stuff.log exists.

6
  • @This statement: .xsession-errors cleared on every restart and copied to .xsession-errors.old, new .xsession-errors created. || Tha tdoesn't happen on my system...
    – RobinJ
    Jun 1, 2011 at 15:23
  • @RobinJ : What release and desktop environment are you running? Jun 1, 2011 at 15:42
  • Linux Mint 10 (Gnome), based on Ubuntu 10.10
    – RobinJ
    Jun 1, 2011 at 16:01
  • Well, I shouldn't have assumed that the file had been growing steadily.. I'm not using Ubuntu as a server, and I quite often restart... I've just checked and even after less than a day, the -old file is up to 473 MB (from 0 MB).. 98.45% of the lines begin with "Debug: Playlist::"... I look intoit further tomorrow...
    – Peter.O
    Jun 1, 2011 at 16:18
  • I couldn't wait untill tomorrow... I just rebooted.. The -old file is now 84 MB (actually, I've rebooted 2 or 3 times today).... So your answer has certainly clarified the startup issue... nothing actively creates and controls the log size log. but rather, something actively shuffles it off to the -old file, thereby basically removing it... very interesitn... Both yours and Robin's answers have been very helpful.. thanks ... (As Robin has technically answered my original qusetion, he gets the green tick :)
    – Peter.O
    Jun 1, 2011 at 16:40
1

I found the command that shows you wich program is accesing wich file. It's lsof.
To find out wich program is using .xsession-errors, you can use lsof | grep .xsession-errors. Additionaly, there's also fuser. It's a bit easier to use in my opinion.
You can just use fuser .xsession-errors. It will give you the file and the PID of the process wich is using the file. Adding -v makes it also show you the name of the program itself. Adding -k will just kill the processes wich are using the file.

1
  • 2
    @Robin.. Thanks for your extra effort, However, many PIDs/apps have the log open, and as the ...-old file is made sometime at startup, it will be tricky (if at all possible) to use this method... but it's good to see fuser and lsofin action.... (On a side note: It is normal protocol on this site, and other stackexchange sites, to contain your answer to a single entry as it keeps the line-of-thought in the same place. Editing your original answer is the way to go, unless your new answer takes an *entirely different twist, and would just make the original answer messy).
    – Peter.O
    Jun 1, 2011 at 16:04
1

My fix is the following:

daily cron job: tail ~/.xsession-errors > ~/.xsession-errors

I'm not really in the mood to figure out which Ubuntu package is broken. This doesn't happen on my non Ubuntu systems.

Please note that this will effectively be the same as just >~/.xsession-errors, i.e. truncating the file.

There's also a way to permanently redirect .xsession-errors to /dev/null, see here.

1
  • 4
    If you're not in the mood, be helpful and don't answer questions.
    – 93196.93
    Mar 16, 2012 at 11:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .