/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.

[Larry De Clay]

Jude,
Somebody turn on the auditing and the output files are in /var/audit.
If you doesn´t take care of that you could delete them. The best way is delete the oldest.

Good luck,
Larry

[Harmanjit_1]

Hi,

You can stop and then restart audit process again which will automatically zip this 14gb file and free up the space and will create new log file.

/sbin/init.d/audit stop

and then

/sbin/init.d/audit start

[DCAdmin_1]

Thank you all for your suggestions. I deleted the audit files and kept the most current. This forum is great and I will definitely continue to log in here to get help. I would like to get to a point where I can help someone as well. Have a great weekend.

[Ann Majeske]

For more information on the Audit subsystem see Chapter 3 of the Security Administration manual and the man pages for auditd, auditmask, and audit_tool.

You should probably reconfigure auditing to use up less space, depending on what your auditing requirements are. Does your company have a Security Policy that you are required to follow? This would have your auditing requirements in it. If you have a requirement for auditing you probably also have a requirement for saving the audit logs for a certain period of time, so you might want to look into setting up a procedure to periodically backup and delete old audit logs.

Ann

[Ann Majeske]

One other thing, you don't need to stop and restart the audit daemon to start logging to a new file the command:
# auditd -dx
will empty the audit buffers into the current log file and start logging to the next file, see the man page for auditd for more details.

Ann

[Manish PATHAK_2]

If the problem is still there can you please check whether collect utility is running or not and if yes then at what time interval....

because it generates so many files andcan also be one of the reason...

Further it will be very useful if you can submmit the output of following commands...

ls -als /var
df -kh
du -sk /var

Regards
Manish Pathak

[Pushker Sahai]

you can use
#cleanup -c 3
#cleanup -c 2
#cleanup -c 1

to delete superseeded patches and this can
give you some space on /var