What to delete?

[Don Spare]

I just received a notification that my /var directory is 91% full. I went looking for what would have put it over the 90% mark and found a few things - one of which was a mail.log file under /var/adm/syslog. I also found a directory, /var/adm/crash/crash.0, that has a group of compressed files dated June 3, 2001. Since they are so old, is it okay to delete them??

Additionally, under /var/adm/sw/products and /var/adm/sw/save there are loads of directories which seem to be related to any patches that may be installed. Is there any reason to keep these? Or can they be deleted too?

Any advise about these would be greatly appreciated.

[Robert-Jan Goossens]

Hi,

HPUX has a great utility to cleanup old patches. just run it !

# cleanup -c1 -p (preview)
# cleanup -c1

Regards,
Robert-Jan.

[Alzhy]

The crash files you could safely delete. But most significant would be to clean up your patch backout files (/var/adm/sw...)..

Use cleanup(1M) command to do this.

[Jean-Louis Phelix]

Hi,

You can delete the crash.0 directory. 2 years is a bit too long to care about analysing the panic. You could also try a 'cleanup -c 2' to suppress patches already superseded twice. Last, you can use sam to trim your log files (SAM, Routine tasks, system log files). Sam will help you doing it in the correct way which is not always the same ...

Best regards,

Jean-Louis.

[Rainer von Bongartz · Accepted solution]

files in
/var/adm/crash/crash.0
has a crash information from June 3, 2001.
you might delete this.


/var/mail.log can be trimmed if your are not interested in sendmails log files . (cat /dev/null > /var/mail.log)

Don't delete anything from /var/adm/sw/products and /var/adm/sw/save .
You might run into trouble when installing additional products or new patches.

I created a seperate logical volume and mounted this to /var/adm/sw.

Regards
Rainer

[Geoff Wild]

You can

cat /dev/null > /var/adm/syslog/mail.log

Commit your patches as well:

/var/adm/sw/save # swmodify -x patch_commit=true *

Rgds...Geoff

[KapilRaj]

Hi,

I am talking of something diffrent but does make sence under this context. There could be chances of such processes which open large files in this filesystem and have not closed it (inodes are not returned) probably somebody else deleted it. You know what happens at this time ?. You will be left out with a filesystem 100 % and can't find the large files !!! :-(

The best way is to do an lsof on this node and search for /var . It will show all those processes which has opened /var filesystem. Check for the old processes and make sure all the files which they have opened are present in /var. IF THEY DO NOT EXIST !! , HE IS THE PROBLEM .. KILL HIM first and you will find your filesystem ok :-)

.....Kaps

[Todd McDaniel_1]

Also, make sure that if anything is writing to /var/tmp it is linked to /tmp and not actually under /var.

Many applications use /var/tmp and not /tmp. So, it is common to rdir /var/tmp directory and then ln -s it to /tmp.

IF you have anyting in tmp move it to /tmp first then ln -s /tmp /var/tmp.


If cleanup -c 2 doesnt clear up your /var then do cleanup -c 1 and commit all patches...

On the off chance if you ever need to remove them in the future use an ignite tape to recover them or some other backup that you have made.

[Joe Short]

Also look at /var/mail to make sure people are deleting their mail and not saving it eternally.

[John W_2]

Well, you've heard the neat stuff already...
and then there are the old standby.s...

1.
du -sk /var/*| sort -n

Of course, be aware that if you have any links here to other mount points, cleaning up files there won't give you any more space on /var.
And if you have a mount point below /var with its own storage, cleaning that up won't help /var.
For example, in this case:
# ll /var
...
-rw-r----- 1 root sys 29 Aug 20 16:24 jwtmp.txt
lrwxr-x--- 1 root sys 4 Nov 25 09:10 tmp -> /tmp
...
# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol8 1536000 621257 859556 42% /var
/dev/vg02/lvol2 4096000 2268185 1736316 57% /var/opt
/dev/vg01/lvol1 2048000 666667 1295066 34% /var/adm/crash
cleaning up /var/tmp, or
cleaning up /var/opt or /var/adm/crash won't take /var below 42% used here.

2.
Prune or remove any logs or dead.letter files (that maybe shouldn't be in /var, but could be, depending on your users and installed apps... and, maybe some stuff from sam in /var/sam/log.)

3.
Old mail files are always fun to remove: check /var/mail.

4.
If sar is running, you might find stuff in /var/adm/sa you can live without.

5.
You could have some /var/adm/cron logs to prune.

6.
And then there are the ever-popular accounting files in /var/adm: utmp, wtmp, btmp.
HP-UX is usually pretty good about these, so you probably don't need to read up on these if you don't have a problem.

Plus, one more tip:
try split if you absolutely must edit or view a large file.