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
  • 178,446
Peter.O
  • 25,251

4 Answers4

5

logrotate should be able to do that.

RobinJ
  • 9,020
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
  • 37,856
Mark Russell
  • 7,396
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
  • 9,020