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

Lekensteyn
  • 174,277
Peter.O
  • 24,681
  • 1
    FYI - if you haven't found it already, the culprit could be Spotify beta. –  Mar 27 '12 at 19:42

4 Answers4

5

logrotate should be able to do that.

RobinJ
  • 8,910
  • 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 http://articles.slicehost.com/2010/6/30/understanding-logrotate-on-ubuntu-part-1 – Peter.O May 31 '11 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 01 '11 at 01: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 01 '11 at 06: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.

waltinator
  • 36,399
Mark Russell
  • 7,376
  • @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 01 '11 at 15:23
  • @RobinJ : What release and desktop environment are you running? – Mark Russell Jun 01 '11 at 15:42
  • Linux Mint 10 (Gnome), based on Ubuntu 10.10 – RobinJ Jun 01 '11 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 01 '11 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 01 '11 at 16:40
  • @RobinJ : That's odd. I just did a fresh VM install of LM 10 Gnome, and .xsession-errors rotated the same way as on Ubuntu. – Mark Russell Jun 01 '11 at 16:51
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.

Community
  • 1
bill
  • 11
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.

RobinJ
  • 8,910
  • 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 01 '11 at 16:04