full /var filesystem

[Horst Prestin]

I have a new L1000 with 500 GByte /var filesystem. I only install some software and now my /var filesystem is full ??! On an AIX-System after many years of full produktion, /var is only 50 MByte, and I can all time under full prodution increase every filesystem without special software.
I have 2 qustions:
1) How can I increase /var (we have install ON-LINE JFS)?
2) I find many files in /var/adm/sw/save. Can I remove them without having problems sometimes ?
Thanks for help!

[Stefan Farrelly]

First you can tidy up some old saved patches by using the cleanup command. But, if you ever want/need to revert back to these old patches then you wont be able to so be careful not to cleanup too many old patches (go back say 2 levels of old patches).

Also check /var/tmp to see if you can cleanup some old files from there.

If you need to increase /var then with onlineJFS its easy; extend the lvol first using lvextend then use fasdm -F vxfs -b /var and your done. You can do this all online.

[Andy Monks · Accepted solution]

to increase /var do :-

lvextend -L /dev/vg00/lvolXX
fsadm -b

however, I think your problem is patches as you have lots of /var/adm/sw/save

To 'commit' the patches (and therefore you won't be able to back them out) do :-

swlist -l fileset -a name | grep PH > /tmp/patchlist
swmodify -x patch_commit=true -f /tmp/patchlist

[Patrick Wessel]

Maybe that helps:

By default at hp-ux during patch installation, SD-UX makes rollback copies of all files and archive library objects modified. These copies are saved under the "/var/adm/sw/save" directory structure and do occupy disk space.

When desired, this disk space can be regained. Of course, when doing so there will be no way to "uninstall" the patch with swremove(1M). The rollback copies are removed from the system when the patch is "committed".

The process of "committing" a patch is accomplished with the swmodify(1M) command. It is necessary to specify which patch filesets are to be committed; thus, to commit an entire patch you would use a command similar to:

swmodify -x patch_commit=true PHCO_13284.*

Once a patch is committed, the "patch_state" is changed from "applied" to "committed". This can be observed by the following command:


swlist -l patch -a patch_state [PHCO_13284/PACHRDME/English]

The "cleanup" command may be used to simplify this process when only the rollback information for superseded patches is to be removed.


Running the following command will remove space for superseded patches in /var/adm/sw/save:

cleanup -c [number_of_time_superseded]

The new "-c" option is added in PHCO_19550. The cleanup(1) man page explains the new option:

-c
Commit patches superseded at least times.
This option is a front-end to the 'patch_commit'
option of swmodify(1M) that provides an easier
interface to commit multiple patches at once.

Running cleanup -c 1 will display all patches that have been superseded at least one time and then prompt for removal of their rollback information. As with all cleanup options no patch information will be removed without prompting the user first.

NOTE: For more information see the white paper located at /usr/share/doc/patch_pgrm.txt and the man page for cleanup.

[John Palmer]

I had a similar problem a couple of weeks ago. Have you got a huge file called diaglogd_hold_list (I think that it's in /var/stm/logs/sys) ?

If so, then it's a known problem and you can delete it. (Mine was over 500Mb).

[Horst Prestin]

I test fsadm. But, fsadm:" -b Option requires OnLineJFS"
SAM tells me, that I have install OnLineJFS!!
Whats wrong????

[Victor BERRIDGE]

Im afraid if you dont have online-jfs, that you will have to if you wish to extend /var to go into single user, and extend /var NOT using SAM for sam needs /var...
That means
lvextend -L /dev/vg00/lvol8
extendfs /dev/vg00/rlvol8

Good luck
Victor

[Andy Monks]

Check if it's in the kernel :-

grep vx /stand/system

should have vxbase and vxadv

if not present do an ls of /usr/conf/lib and check for libvxfs_adv.a

If it's there, add vxadv to the /stand/system file and rebuild the kernel and reboot.

Clearing the wasted space out is better than needlessly increasing /var IMHO.

Also check what's in /var/adm/crash if anything.

[Andy Monks]

Check if it's in the kernel :-

grep vx /stand/system

should have vxbase and vxadv

if not present do an ls of /usr/conf/lib and check for libvxfs_adv.a

If it's there, add vxadv to the /stand/system file and rebuild the kernel and reboot.

Clearing the wasted space out is better than needlessly increasing /var IMHO.

Also check what's in /var/adm/crash if anything.

[CHRIS_ANORUO]

You can reduce the sizes of the following files to zero with this command:

cat /dev/null > /var/adm/wtmp

/var/adm/wmtp, btmp
/var/sam/log/*.log
Remove the files under /var/preserve and /var/mail.
You can include this clean-up in a cron.

[Horst Prestin]

Hi,

thanks for all your help!!!

The reason was:
Copy the software to depot only install a litle part of OnLine JFS! The option I have to switch of is:
"Enforce dependency analysis errors in agent"
What ever this means?! Now it is working!

Because I have many patches installed, but did not know for what, I have to wait some time before I commit them.

[Bill Hassell]

It's always difficult to compare different flavors of Unix by assuming that directories and filesystems are the same (ie, AIX doesn't grow /var). HP-UX maintains many critical subsystems in /var and if it should fill, *ALL* of these subsystems will fail. A better technique is to run separate filesystems for each busy subsystems. These are:

/var/mail
/var/adm
/var/adm/sw
/var/adm/crash
/var/spool

If you aren't using email on a system, /var/mail can be part of /var, but if you are receiving email, anyone can send a massive message (100's of megs) and fill /var. Same with spooling, etc. /var/adm always needs logfile trimming.