/ file system full !

[arun m govind]

Hi,
In my hp-ux 10.20 system the / file system is 3 gb,used space is 2.3gb.But it is showing the free space as 0.Evenif i delete 500mb file also it show free space is 0.What could be the problem?????/

Regards
Arun M Govind

[Peter Godron]

Arun,
not sure what happened to my earlier mail, but here are some previous posts:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=19566
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=922852

[melvyn burnard]

This is probably due to a running process holding a file open even though you deleted it.
The way to fix this is to find that running process and shut it down, so that it release the space back to the system, or at worst do a shutdown and reboot
If you know what process that 500Mb file belonged to, you could try halting that process first

[Peter Godron · Accepted solution]

Arun,
to repeat my lost post:
Do a:
find / -xdev -size +100000c -exec ls -l {} \;
to show all the files > 100K

use fuser and/or lsof to find active processes that are using the disk.

Remember only after a process has completed is the space released!

Also check /dev for failed backup files.

[Sp4admin]

Hi Arun,

Thats a large amount of space for / directory. The best thing to do is find any large files in the / directory or processes that maybe using the space.

sp,

[Paul Sperry]

I have had this happen to my /tmp directory.
Even after deleting everyting in it it was still at 100% full. A re-boot fixed the problem but that's a crummy solution.

[Bill Hassell]

3Gb is an enormous size for /. You only need 200megs (actually, 100 megs in 10.20). So something is definitely non-standard or wrong in /. Don't bother looking for large files -- this will not find the reason for the space usage! Start by finding the largest directories:

du -kx / | sort -rn | head -20

Post this here in the forum and we can help fix the problem.

This is a typical listing for a 'normal' / listing:

77840 /
33168 /etc
32408 /sbin
14920 /etc/opt
13216 /etc/vx
11768 /root
11024 /etc/vx/type
8584 /etc/opt/resmon
5928 /sbin/fs
4336 /etc/vx/type/gen
3704 /etc/opt/resmon/log
3568 /etc/opt/resmon/lbin
3512 /sbin/fs/vxfs

The most common problem is a spelling error in /dev. Use this command to find the problem:

find /dev -type f -exec ll {} \;

There are *no* regular files in /dev. The most common mistake is /dev/rmt/om which was produced as a spelling error during a backup. It was supposed to be /dev/rmt/0m but most backup programs will create an output file with the requested name if none is found.

Once you find a large directory, you can sort the files inside the directory like this:

ll /somedir | sort -rnk5

Note that removing a file will appear to work OK even when the file is already open by one or more programs (ie, a log file). Logfiles have no business in / but if you remove a large file and nothing changes, the file is stil open. You need to terminate the program(s) using this file to regain the space (or reboot).

[John Collier]

Just a thought, but one of the times I ran across an issue such as this it turned out to be enormous lig files set up by a previous Admin. No idea still yet to this day what they were thinking by putting them where they did, but the result was scary the first time I saw it none-the-less.

If you find that it is something similar with your log or other text files, first of all send them to another disk/box/backup source and then a simple

> /path/to/logfile.name

will clear that file out to a zero size even while it is beign used by the respective process (most of the time).

Just a possible cause/solution situation from my experience. Yours could be very different.