Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

My root disk is full to the brim because of, I suspect, disk space locked up by a ballooning .xsession-errors file. The ballooning is caused by running processes that keep the error file open and dumping data into it, i.e., PID from several different applications e.g., chromium being the largest culprit. I suspect this is the case because lsof | grep deleted returns lines like:

chromium- 27607  user  2w  REG 8,1 1809493864448  108527952 /home/user/.xsession-errors (deleted)
chromium- 27762  user  2w  REG 8,1 1809493864448  108527952 /home/user/.xsession-errors (deleted)

The twist here is that I have a cron job set to delete the file home/user/.xsession-errors` as per a suggested work around to this issue. You can imagine how this situation runs a mock quickly when chromium opens up umpteen processes! I am using a 64bit UBUNTU 12.04 machine with the following HD (EXT4) config:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       1.8T   34G  1.7T   2% /
udev             12G  4.0K   12G   1% /dev
tmpfs           4.8G  1.2M  4.8G   1% /run
none            5.0M   16K  5.0M   1% /run/lock
none             12G  2.1M   12G   1% /run/shm
/dev/sde1       1.8T  450G  1.3T  26% /media/SEA2T
/dev/sdd1       2.7T  201M  2.6T   1% /media/BUFF3T
/dev/sdb        3.6T  118G  3.3T   4% /media/INDAR
/dev/sdc        3.6T  3.0T  469G  87% /media/ALAYA

What I've done so far to resolve in vain:

  1. Is it possible to reclaim this space? Apparently not in my case, though others have managed to truncate the file to free up the the disk.
  2. As this seems to be a sort of virtual occurrence, with no real file(s) as culprit, rebooting was the working option for me.
  3. How To ensure this doesn't happen again? I still don't know. The current workaround is setting the ERRFILE variable in the file /etc/X11/Xsession to /tmp/$USER-xsession-errors

in order to figure out what is being dumped to this error file. I appreciate any suggestions as to how to deal with the run away xsession-errors file once and for all! Thanks in advance.

share|improve this question
    
You're saying your ~/.xsession-errors file was 1.7 terabytes in size? I don't think that sounds right. Also the file is rotated every time you log into the system. I never log out, unless I have to reboot for a new kernel. My current uptime is almost 7 days, and my .xsession-errors is less than 3MB. The .xsession-errors.old is only 5.2M and I think it was a much longer session. –  dobey May 29 '13 at 2:12
    
Yes! What does the lsof output say to you @dobey? My understanding is that 1809493864448 is the size of a regular file. Assuming unit bytes that is ~1.6T! And there were numerous entries for different PIDs with large REG entries referencing ~/.xsession-errors. I cannot prove to you the file size physically, because it was routinely deleted by a cron task. –  Kambysese May 30 '13 at 19:59
    
You need to run tail -f ~/.xsession-errors in a terminal, and see what exactly is writing to the file. I use chromium, firefox, and plenty of other applications here, that write excessive text to stderr/stdout, but my xsession-errors file never grows that big. I've never seen it grow that big, ever, even. –  dobey May 30 '13 at 20:39

1 Answer 1

You might be able to access the file through ls -l /proc/<PID>/fd/* (dangerous) and once you've determined the fd number, truncate it with truncate /proc/<PID>/fd/<fd> --size 0 (even more dangerous). That's the alternative to rebooting or killing the process. However it's hard to tell what will happen on subsequent writes to such a mutilated file.

What you really should do is find out what is writing to that file and why and take whatever steps necessary to stop it from doing that. Even ignoring storage issues, writing debug logs is expensive and hurts performance. Thus you should find the root cause.

share|improve this answer
    
Thanks @frostschutz can you explain in laymen why listing fd and truncating are dangerous? I didn't actually manage to truncate, but was convinced that processes were virtually taking up space, so I rebooted. Trying to figure out what is going on but in the past 24 hours my redirect to /tmp/$USER-xsession-errors has not actually produced the log. For now I am stumped. –  Kambysese May 29 '13 at 19:12
    
A process usually does not expect its file handle to be tampered with from the outside. And there are pitfalls such as if the process closes the file and reopens another one, you might end up truncating the wrong file. –  frostschutz May 29 '13 at 20:47
    
Thanks for the explanation, +1 @frostschultz –  Kambysese May 30 '13 at 19:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.