5

I'm using Fedora 12 on my laptop. I have 10GB disk space and 2GB of them are free. After 2-3 days uptime the space ends and I must reboot. After rebooting I get 2GB free space back. How can I prevent this?

Mostly I use Firefox, Chrome, Gedit, Rhythmbox and in background: httpd, mysqld, conky. RAM: 1GB, Swap: 1.2 GB.

4
  • What's using the space? Next time you run out use one of the tools in this post to find what files are consuming all the space (possibly in /tmp) Nov 13, 2010 at 5:09
  • I tried to clean /tmp folder but after that system unable to work
    – NARKOZ
    Nov 13, 2010 at 5:18
  • 1
    Could it be your logs in /var/logs?
    – fox
    Nov 13, 2010 at 6:00
  • 2
    Don't blindly delete files in /tmp; in particular, if you delete /tmp/.X11-unix/X0, you won't be able to start GUI programs. If you see a large file there, try to work out who is using it, don't delete it if you're not sure you can do it safely. Nov 13, 2010 at 12:15

2 Answers 2

5

Firstly, you must find out what is eating away at your space. I'd suggest you track down the physical file or directory that grows to that size.

The simplest way would be to check the directories in / using: ( I'd suggest running it as root )

 # du -hs /* 2> /dev/null
4.2M  /bin
25M   /boot
204K  /dev
6.7M  /etc
19G   /home
112M  /lib
16K   /lost+found
12K   /media
16K   /mnt
4.0K  /multimedia
1018M /opt
0     /proc
15M   /root
8.6M  /sbin
12K   /srv
4.2M  /storage
0     /sys
108K  /tmp
16G   /usr
4.3G  /var

Now, You run that when the computer has freshly started and has not started to eat space yet and you save the output in a file ( ~/record-space )

$ sudo du -hs /* 2> /dev/null 1> ~/record-space

And then when your computer is nearing a "FULL" state, you can run the command again saving the output in a second file.

$ sudo du -hs /* 2> /dev/null 1> ~/record-space2

Now you can compare these two files ( ~/record-space and ~/record-space2 ) to see how th e main directories differ...

My favourite way of comparing files is using diff:

$ diff ~/record-space{,2}

update: See Gille's comment to this answer.

Instead of du -hs /*, rather use du -xsh /tmp/* /var/*/* ~/.*.

2
  • 1
    As 'ugly' as this solution sounds, I highly recommend it in this case.
    – N J
    Nov 13, 2010 at 9:55
  • 2
    I suggest du -xsh /tmp/* /var/*/* ~/.* as the du command. The directory list should catch the most likely locations, and the added -x is to skip other filesystems (e.g. RAM disks, USB drives). Nov 13, 2010 at 12:13
2

Some distributions or desktop environments can show a warning if your available disk space drops below a certain threshold; here's how you can cobble your own. In a terminal, type crontab -e (not as root); this will pop up an editor. Enter the following line:

*/5 * * * * if [ "$(df -P / | awk 'NR==2 {print $4}')" -le 1048576 ]; then df /; fi

This means every five minutes (*/5 * * * *), if the free disk space ("$(df -P / | …)") drops below ([ … -le … ]) 1048576KB (1GB), send you a local mail with the free disk space (cron will send you the output of df /).

You may notice that the “used” and “available” columns only account for 95% of the total; that's because of the reserved space and is not responsible for your problem (the reserved amount does not vary over time).

The most likely places where something might be eating up your disk space are /tmp, /var and your home directory (including their subdirectories). I second Stefan's tips on setting up a baseline du output and comparing it with the output when the disk is full.

If the space is freed when you boot, there can be several reasons. Some program is presumably creating large temporary files; maybe these files are cleaned up when the program terminates, maybe they're cleaned up during the boot process, maybe they're cleaned up when the program starts again. One case that you won't be able to observe with du is if the large files are deleted while the program is using them. When you delete a file on a unix system, only the file's name disappears at first (the file is “unlinked”); the file's contents only disappear when there are no longer any references to the file: neither a name nor a process having it open. In other words, if a program creates a large file, opens it and deletes it, the space is only reclaimed when the program closes the file (which happens automatically when the program dies). You can't see deleted files with du, but you can see them with lsof (“list open files”):

lsof | grep '(deleted)'

In the lsof output, the next-to-last number before the file name (i.e. the 7th column) is the file size.

You must log in to answer this question.

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