/var is at 90% capacity

[DCAdmin_1]

I am new to Tru64 UNIX V5.1B. I was given responsibility for a ES40 server. Lately, the /var has hit 90% capacity and I have no idea what is taking so much space. I have looked into whatever log files and directories and didnt see enough to help me reduce the amount of space. I have read some things about quota files, but I am not sure if thats the cause. Please advise. Thanks.

[Victor Semaska_3]

Hi,

Quota files probably wouldn't be the problem. Use this command as root:

# find /var -exec ls -s1 {} \; | sort -k1,1nr | more

This will list files sorted by size in KBs largest files 1st.

Vic

[Ivan Ferreira]

Use find . -type f -ls |sort +6 -nrb |head -10 to find out the top 10 large files.

You should check for unreaded mailboxes on /var/spool/mail

Also use:

du -sk * |sort -nrb

To identify the biggest directory.

[Steven Schweda]

90% of what? How much is "so much space"?

[Harmanjit_1]

you can check following things :-

1. /var/spool/mail and see any user mail is having more size.
2. /var/adm/crash, if crash dir contains core files.
3. zip the old /var/adm/syslog.dated/ directories which are not required.

Hope this will clear most of the things. If you still couldnot make the space use du -ks /var and see which dir is taking more space.

[Venkatesh BL]

What is the total size of /var file system? Does 'var' fileset belong to usr_domain itself?

[Steven Schweda]

> [...] use du -ks /var and see which dir is
> taking more space.

Close, but "du -ks /var" will tell you about
"/var" as a whole, not about the directories
in "/var".

Perhaps "du -ks /var/*", as was suggested
(more or less) earlier.

Trying this stuff before posting it might be
more helpful.

[Don Ritchey]

Another thing to check is to see if you have long-running processes with output files that have gotten unlinked (removed). If you have a daemon process that had its output file placed in /var/tmp and the file has been removed (but the space still allocated), then this will consume space invisibly.

Check for this condition by comparing the output of df (disk free) and du (disk used).

df /var

du -sk /var

If the values for space used differ by more than a few megabytes, then check to see if you have any long-running processes with files open in /var that do not have corresponding file entries in the file system. The main tool I use for this check is lsof (LiSt Open Files) available from ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof

[DCAdmin_1]

Hello All,

Thank you for your replies. Steven's suggestions helped alot with the du -ks /var/*. It narrowed it and turns out that the /var/audit directory was the biggest directory. The filesystem has 16GB and the /var/audit is taking up over 14GB.

This leads to this question, can I delete the auditlog..###.Z files listed? They are huge files. Please advise. Thanks.

[Steven Schweda]

urtx# ls -l /var/audit
ls: /var/audit not found

Clearly, none of that stuff is needed.

Of course, mine is only a hobbyist system,
and does nothing very important.

"man -k audit" does offer some stuff,
including:

audit_tool, audit_tool.ultrix (8) - Audit log reduction tool

auditconfig, audit_setup (8) - Audit subsystem configuration graphical interface (Enhanced Security)

So, I know nothing, but I'd bet that
there's a manual somewhere. My guess is
that if it makes sense to collect these data,
then it probably makes sense to archive them
(possibly) and to purge them (certainly).

If you didn't even know the data were there,
they may not be too important, but I also
tend not to throw anything away (totally),
especially when I don't know its purpose
and/or value.