Var directory grows up to 99%

[Sandile]

hi all

Can I get help with the subject above.I did remove the log files,removed core files and trimed all logg file to the recomended size but there is no change on my /var.Fisrtly it was at 100 % and after I performed the above commands its sitting at 99%.

[Stefan Farrelly · Accepted solution]

What you need to do is find out which directories are the largest so as this is the easiest way to free up some space.

cd /var
du -sk * | sort -n

This will list the largest subdirs under /var last - then you can cd to them and again do the du command or see if theres some large files in there you can remove or trim down.

Can you add some space to /var ? It does grow a lot and we often have to increase ours or make them large in the first place.

[Robin Wakefield]

Hi,

Also make sure the processes that were writing to the files you've removed are not still running. See:

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

for a full discussion.

rgds, Robin

[Armin Feller]

You can also search large files:

# find /var -size +1000000c -exec ll {} \;

And there are a lot of log files in /var. A lot of space can be freed by removing old system crash files in /var/adm/crash.

[Balaji N]

hi,
as pointed already check which directory is using the space. also, if u have been installing patches, u could remove the already superceeded old patches.
checkout the manpages for cleanup for more details.
hth
-b-

[Pete Randall]

You will probably find that /var/adm/sw is rather large - DO NOT remove anything from this directory. It contains all the save info from patches that have been applied to your system (in case you want to do a swremove later). Removing things directly from here will completely mess up your patch database. The only safe way to clear old patch info is with the cleanup command: cleanup -c 1 (or 2, or 3). Do a man on cleanup.

Pete

[T. M. Louah]

The trick is to find large Directories not big files, sort all sib-dir under /var by size:
# du -kx /var |sort -rn > /tmp/du.var
now look in /tmp/du.var the first few should be ur largest dir, look inside of them & sort content by size:
# ll |sort -rnk5 |more

Cheers,
T??
PAP ! (a.k.a. Pliz Assign Points )

[Patrick Wallek]

A good place to check as well, especially if you have diagnostics installed and running, is /var/stm/logs/sys and check the log files there.

If you have some type of hardware problem the activity.log file can grow to be VERY LARGE.

[Ross Zubritski]

Ensure that any of the files that you removed did not have a background process attached. If the file was removed and the process is/was still active, the inode table will be hung until the process releases.

RZ

[Colin Topliss]

I can't tell from your mail how you have your filesystems laid out. Is /var one large filesystem (for example, we have a separate filesystem for /var/tmp)?

If its one large filesystem, it may well be you have a large number of small files in /var/tmp. T.M Louah's idea might point you in the right direction.

Of course we don't know what % free you had before your problems started - perhaps /var was not sized correctly in the first place, and you should look at extending it?