/var full

[Marco Antonio Hernandez]

Hi there!!!

I'm using a HP-UX v11 with 2 rp5470 in cluster configuration. Is there a way to know the real free space on those disks, they're in cluster configuration...because the /var is full it seems there's no way to free up space, if anybody can help...it will helpfull...
Best Regards,
Marco Hernandez

[James R. Ferguson]

Hi Marco:

# du -kx /var|sort -k1rn|more

...will produce a descendingly sorted list of the largest directories and files. Do *NOT* manually manage the 'var/adm/sw' directory or its contents! This is your IPD (Installed Product Database). Corruption or deletion of entries herein will render you server unpatchable.

Instead, use:

# cleanup -c 1

...to regain space. See the 'cleanup' man-pages for more information.

Aside from trimming log files like 'wtmp' ('> /var/adm/wtmp'), you can remove old '/var/adm/crash' dumps (if any) and look for old, unused 'vi' recovery files in '/var/preserve'.

Regards!

...JRF...

[Court Campbell]

To add to JRF's post you can also use du in /var/adm/sw/save to find large patches. Then you can use swlist to find out more about the patch. You will have to judge whether the patch can be committed or not, but if so you can use this command.

swmodify -x patch_commit=true patch_name

I will note that once you do this you will not be able to back out of the patch. Ah, the peril's of being a sysadmin.

[Steven E. Protter]

Shalom,

If you have ever patched


cleanup -c 1
or (brain freeze)
cleanup 1

Also use sam routine functions and trim your log files

SEP

[SKR_1]

You can find the bigger files inside /var with below command.

find /var -xdev -size +10000000c -exec ll {} \;

You can clear the syslog.log, mail.log or you can gzip the sar files inside /var/adm/sa directory. Also you can remove the older crash directory if it is there inside /var/adm/crash.

Thanks

SKR

[Doug O'Leary]

Hey;

Other things to look into:

/var/adm/syslog/*
* maillog and syslog.log can be quite hugh
/var/adm/*tmp*
* login logging grow without bounds.
* If you're interested in maintaining these (and you should be) examine fwtmp and wtmpfix man pages to learn how to truncate them.

Doug

[G.Sivakumar]

use "du -sk * |sort -rn" to find the size of the files and directories.
you can trim the syslog files..
you can delete the files from /var/spool/mqueue.

[Prashanth Waugh]

Hi

check which is consuming more space using
#du -kx |sort -nr | more
then trim it by using
#> file

but delete it accoring to your IS policies.

Reagards
Atul

[prasadb]

Along with all the option given by the experts, you may find unnecessary files at the following locations :


/var/mail =======> truncate the mails here

/var/tmp ========> check these file and remove

/var/opt/ =======> check logs here

also see,

/var/opt/ignite ===> here in log and tmp folders you may remove the data..

[Deepak Kr]

Hi,

Trimming syslog is not recommended as anytime you need this info for diagnostics...

SEP and James are absolutely correct here.

First find the big files and analyse if these are currently in use .

Also cleanup will free some space here.

No problem even if you are running cluster on this system...if free space is there you can add some space into it.

Paste...following output.

find /var -xdev -type f -exec ls -lrt {} \+

and

bdf /var

and

swlist |grep -i onlinejfs

[Mark McDonald_2]

It is not always best practise to look for/remove or trim larger files. Only do this if you know what they are and are sure you do not need them.

Sometimes it is a lot of smaller files that are better candidates for deletion, but these are harder to track down and do not give the quick wins.

[MarkSyder]

If you want to trim logfiles you might like to consider using SAM. This will trim the files to a predetermined size (which you can set if you do not want to keep the system default). This is useful as it keeps the most recent information - the information you might want to refer to.

Mark Syder (like the drink but spelt different)

[Marco Antonio Hernandez]

Hi everybody,

Your replies have been very usefull, I found the following:

1. In /var/tmp/dp

-rw-r--r-- 1 root sys 34201600 Sep 30 2003 PHSS_29143.depot
-rw-r--r-- 1 root sys 14790 Oct 1 2003 PHSS_29143.text
-rw-r--r-- 1 root sys 972800 Sep 25 2003 PHSS_29411.depot
-rw-r--r-- 1 root sys 10687 Sep 29 2003 PHSS_29411.text
-rw-r--r-- 1 root sys 17382 Sep 29 2003 PHSS_29414.text
-rw-r--r-- 1 root sys 4249600 Oct 30 2003 PHSS_29423.depot
-rw-r--r-- 1 root sys 30290 Oct 31 2003 PHSS_29423.text
-rw-r--r-- 1 root sys 42588160 Nov 17 2003 PHSS_29867.depot
-rw-r--r-- 1 root sys 24609 Nov 19 2003 PHSS_29867.text
-rw-r--r-- 1 root sys 68505600 Dec 1 2003 PHSS_29869.depot
-rw-r--r-- 1 root sys 21677 Dec 2 2003 PHSS_29869.text

and these:

/var/adm/crash/crash.0
#
# ls -la
total 392992
drwxr-xr-x 2 root root 8192 Sep 14 2004 .
drwxr-xr-x 4 root root 96 Dec 21 2006 ..
-rw-r--r-- 1 root root 1197 Sep 14 2004 INDEX
-rw-r--r-- 1 root root 33550336 Sep 14 2004 image.1.1
-rw-r--r-- 1 root root 33525760 Sep 14 2004 image.1.2
-rw-r--r-- 1 root root 33525760 Sep 14 2004 image.1.3
-rw-r--r-- 1 root root 33488896 Sep 14 2004 image.1.4
-rw-r--r-- 1 root root 33525760 Sep 14 2004 image.1.5
-rw-r--r-- 1 root root 5378048 Sep 14 2004 image.1.6
-rw-r--r-- 1 root root 28177128 Sep 14 2004 vmunix

Those files are very large, but the PHSS I think they're patches or something like that, it is possible to move them to /tmp on root directory then delete them form where they are now?

And the same quiestion for files on crash.0 directory.

I need your advise 'cause i don't know if they're in use or not, some time ago i cp some files from /var to /tmp to freeup space...well i'll wait your advises.

Best Regards,
Marco Hernandez

[Court Campbell]

You could more than likely delete the depot files. They are pretty old. Removing them won't hurt anything. If anything you may just want to back them up to tape, remove them, and see if anyone complains. If so restore them to another location. And your crash dump is also old. You could remove it.

[Tim Nelson]

I concur with Court.

Delete or move the depot files, you can always download again.. These are SD depots used to install patches, not actually active files on the system.

Delete or move the crash dumps.

The action is up to you...

If you need the crash analyzed then keep them somewhere else.

If you need the downloaded depot distros then move them somewhere else.

In a nut, these files are not needed for the system to run. They could be needed by you to admin the system.

[James R. Ferguson]

Hi Marco:

Ditto to Court and Tim's recommendations to remove the patch depots and the crash dump images.

Consider that the patch files can always be re-feteched *AND* have probably had superseded versions made available anyway.

Consider that a 4-year old crash dump is meaningless --- it's 4-years old so it hasn't happened again --- why keep it?!?

Regards!

...JRF...

[Marco Antonio Hernandez]

IT WAS JUST GREAT !!!

GUYS...everything that you told me was right now /var is 87%, i backed up the PHSS, just in case, and the crash.0 files are gone.

Now the application AAA it seems that will have some space to work.

I want to thank you for all your great help.

God Bless everyone.

Best Regards,
Marco Hernandez