Out of disk space, what's the source?

Question

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  220G     0 100% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  220G     0 100% /var/lib/ureadahead/debugfs

while panicking searching for answers after what seemed like ages the use decreased

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  9.3G  200G   5% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  9.3G  200G   5% /var/lib/ureadahead/debugfs

I haven't deleted anything so far and the and now that I'm writing this its back to

/dev/sda1             220G   12G  197G   6% /

What happend?? How can I investigate the cause and set things so it doesn't happen again I prevent this from happening again

During the time of the massage usage I found that the size of the /var folder was constant at 1.8 gigs but I was not able to check all folders

edit gone up to

/dev/sda1             220G   18G  192G   9% /

* update 2* It's going up again

ubuntu /: df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G   43G  167G  21% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G   43G  167G  21% /var/lib/ureadahead/debugfs

And checking the command I was given

ubuntu /: du -h --max-depth=1 /
31M     /boot
4.0K    /selinux
8.0K    /srv
7.4M    /bin
du: cannot access `/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access `/proc/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/fdinfo/4': No such file or directory
0       /proc
12K     /tmp
2.4G    /var
0       /sys
100K    /root
4.0K    /media
575M    /usr
4.0K    /opt
16K     /lost+found
4.5M    /home
270M    /lib
168K    /dev
4.0K    /mnt
6.7M    /sbin
6.1M    /etc
4.0K    /cdrom
3.3G    /

note the 3.3G for /

Answer 1

I think you have something writing to a file that has been deleted from the drive but not yet closed by the application/server, so the space remains allocated on disk but can't be seen by du since the file was removed from the filesystem. The lsof program lists processes that have files open. If you had more filesystems mounted and the number didn't fluctuate so much, then I would have suggested that you had a filesystem mounted on top of a directory that wasn't empty (though you could try umount /var/lib/ureadahead/debugfs and make sure that directory is empty and there isn't a bunch of junk written to the directory hiding under that mountpoint).

If this is the case, then you should easily find these with sudo lsof | grep deleted. lsof includes (deleted) in the last column if a file has been deleted while a process still has it open. The first column is the name of the command, the second column is the PID. You can get a more detailed look at the command using ps for instance ps auxww | grep PID, or ps auxwwf | less -S to see the process list in "forest" mode so you can see what process that PID came from. Once you've tracked down the process(es) that are holding open giant files, you can stop it to free the drive space, then figure out how to fix it to close the file properly. The usual cause of this is a logrotate script that renames/deletes log files but doesn't notify the application that it has done so (either through an appropriate signal with kill or by restarting the application), so the application continues to hold the old log file open.

Answer 2

Run

du -h --max-depth=1 /

And it should give a clearer picture. If its coming and going it sounds like temp files being created and then not deleted once done with, until whichever process is causing it crashes. What OS is this server runnng and is it running anything in particular?

Answer 3

It looks like the problem is /var/lib/ureadahead/debugfs. It appears this is a known problem, here is a link to ubuntuforums with more information http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04. The tl;dr seems to be update and upgrade, sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, then reboot. Of course, I am assuming you are running 10.04.

Answer 4

My guess is the log files; I had so many PHP 5.3 "deprecated" warnings in my Apache logs on a dev server that I wasn't really paying attention to that it chewed up all 8GB of space on my var partition (as a sidebar to the problem: you should always put /var on a separate partition that your root partition as running out of space can cause system instability issues).

Answer 5

If the space was consumed very quickly (not in ages), Its probably just file allocation.

The cause could be huge swap or temporary files for some application, Which are emptied after its process.

Do a du --max-length=1 when space is consumed a lot.

If you think your root folder is taking too much (3.3 GB) try ll -a / and post the results.

Answer 6

It seems like /var/lib/ureadahead/debugfs may be a red-herring. Here's why...

While /var/lib/ureadahead/debugfs does exist in /etc/mtab, it is not found in /proc/mounts:

$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0

The df command seems to be reporting exactly the same thing for /var/lib/ureadahead/debugfs and /

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   1681128   8115792  18% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   1681128   8115792  18% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Creating a 1GB file in /tmp:

$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s

Shows the size reported in both places:

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   2730216   7066704  28% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   2730216   7066704  28% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

So, it seems like /var/lib/ureadahead/debugfs device is a red-herring as it is just mirroring the stats from /. If you are running out of space, it is due to something filling up your root filesystem. I would check your /var/log first.

Answer 7

The problem was being initiated by a cron task executing a php CLI command every minute. The PHP code seemed to be stuck in some kind of insanity loop of caught errors and massive amount of debug data growing at the speed of the processor.

As the php code being executed took longer than a minute it did not consider the job done, it kept executing again and again increasing the speed of the growth of the (temporary?) data.

The same task has been running for close to a month with no problems, so it was not in my mind as a cause.

The strange thing is that the php script sets the max execution time manually

I checked the php.ini for clues

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

It says that values are hardcoded to unlimited for the CLI! O_o