Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
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) –  Michael Mrozek Nov 13 '10 at 5:09
    
I tried to clean /tmp folder but after that system unable to work –  NARKOZ Nov 13 '10 at 5:18
1  
Could it be your logs in /var/logs? –  fox Nov 13 '10 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. –  Gilles Nov 13 '10 at 12:15

2 Answers 2

up vote 5 down vote accepted

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/*/* ~/.*.

share|improve this answer
1  
As 'ugly' as this solution sounds, I highly recommend it in this case. –  N J Nov 13 '10 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). –  Gilles Nov 13 '10 at 12:13

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.

share|improve this answer

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.