/var file system keeps filling up

[Amiel Tutolo]

I have looked and looked at this file system and I cannot see what is filling it up. The original sysadmin installed Backup Express software on this file system and I believe this is causing the problem. What is the easiest way for me to determine who or what keeps adding space to this file system. An example is I moved a 600MB file but after only a few minutes I lost 200MB of this to something or someone. I am talking with the vendor so I can move the backup software. Are there unneeded directories or files in /var that can be moved or linked to another file system? I am lost. Any help would be appreciated. Thanks

[Helen French]

Hi,

Try these commands:

# find /var -xdev -size +1000 -exec ll {} \; > /tmp/bigfiles

# find /var -xdev -type f -mtime -1 -exec ll {} \; > /tmp/newfiles

Find the big files and newly created files.

HTH,
Shiju

[Jeff Schussele]

Hi Amiel,

While in /var do a:

#du -akx | sort -nr | head

This will list top ten large files in /var FS, only, in descending order.

Repeat frequently to see which files are chewing up the space.

HTH,
Jeff

[Helen French]

Hi,

Another thing is to remove files from /var/adm/crash directory, if you don't require the crash files.

Also if you find a particular file growing continously, then check the log files. It might be reporting some errors.

HTH,
Shiju

[S.K. Chan]

One method you can use to track down which "new" or "updated" files in /var is to create a "timestamp reference" file (say file "ref") and use the find command to tell it to show you all the files which are newer than file "ref".
Example ..
# cd /var
# touch ref
# find . -xdev -type f -newer ref

[Roger Baptiste]

hi,

other than the excellent suggestions offered by others, try lsof on /var to see what processes are writing on them. the list may be long, but it will give you an idea in case there are processes dumping huge files.

lsof is a free tool and is available from the portable archive source.
HTH
raj

[Martin Burnett_2]

Hello,

Another thing to look at is top, see if you have any run away processes eating up a lot of cpu. Many times these same processes use the /var file system to log activity. For instance there was a known issue with diaglogd the caused the /var/stm/data/diaglogd_hold_list
file to grow rapidly. The first a user new about it was when the /var file system was full. The same has been a issue for cclogd.

HTH
Martin

[Sandip Ghosh]

You can run cleanup -F
OR
you can go to the following link and find out which file is increasing and accordingly take action. The solution given by Robin is good.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x11cb0bce6f33d6118fff0090279cd0f9,00.html

Sandip

[Deshpande Prashant]

HI
You might reduce space in var used by superseeded patches.
Use #cleanup -p -c 2 to see list of such patches.

Still use the lsof command to find the culprit process dumping big files in var.

The older version of Online diag had bug of dumping big files in /var/stm/ dir. Check it

Thanks.
Prashant.

[James George_1]

try # du -sk * | sort -n in /var and find out which dir has the maximum space. If none of these works out , it is sure that some process is holding the space. Try to find out that process and kill that and your /var will be released from filling up.

James

[Rodney Hills]

If you have a lot of large print jobs, then /var/spool/lp could be using a lot of space. If this is a problem, you can limit users by using disk quotas.

-- Rod Hills

[SHABU KHAN · Accepted solution]

Amiel,

cd /var
hostA>ls -lR | grep ^- | sort -nr -k 5 | more

This will list all files in descending order on /var

The next thing I would do is to check all processes writing to /var, as suggested earlier lsof will do the trick

>lsof | grep "/var"


-Shabu

[Amiel Tutolo]

Thanks for all the great answers. I have assigned all points and each answer helped me to either solve the problem or learn something new. I did find out that there were two things going on - My Backup Express software catlaog has a condense tool and when this runs it needs to be able to create the catalog for a backup and then condense and delete one. There wasn't enough room. Also our Accounting dept. was printing large forms from Oracle Financials. Thanks again.