/var filesystem

[Scott D. Allen]

I'm trying to expand my /var filesystem on a remote server. Do I need to be in Single-User mode to do this? I did an fuser -c /var and it came up with some processes (cron, ptdaemon, vtydaemon, rpcd, netfmt, syslogd). I'd rather not bring the system down if I don't have to. Can I just kill the procs and umount the filesystem after I lvextend?

Also. The lv that /var is on is mirrored. If I lvextend the lv, do I have to do anything special because it's mirrored, or will lvm automagically expand the mirror?

--Scott

[Rick Garland]

Would be best to boot into single-user mode to extend /var. There are many open files and processes associated with /var.

/var does not have to be contiguous.

[Patrick Wallek]

I would not try to kill all the processes that are accessing /var. I don't know if you'd ever get them all killed.

If /var happens to be a vxfs file system and you have the Online JFS product (an extra cost product) then you don't have to do anything, you can extend the filesystem on the fly. I LOVE vxfs and Online JFS for that reason.

Otherwise your best bet would be to boot into single-user mode and go from there.

[Kofi ARTHIABAH]

As Rick indicated, it is advisable to go to single user mode but since in your case you cannot, you might want to gracefully terminate the processes before umounting /var.

most of the processes that show up when you do fuser -cu /var should be terminated by stopping them from their respective /sbin/init.d scripts. so for example

/sbin/init.d/rpcd stop
etc. etc.

[Scott D. Allen]

Thanks guys. That's what I was afraid of. I'll probably try to use the init scripts, but if necessary I can use a modem to dial in and bring 'er down to S.

No answers on the lvextend (mirrored) question?

--Scott

[Rick Garland]

You will have to be on the console when you go into single-user mode. Boot into single user mode. Doing the init S is not a true single user mode. Filesystems stay mounted, networking is active, etc...
It is something you would have to be present for.

Doing the modem will not allow you to boot into single-user mode.

[Rick Garland]

You will have to be on the console when you go into single-user mode. Boot into single user mode. Doing the init S is not a true single user mode. Filesystems stay mounted, networking is active, etc...
It is something you would have to be present for.

Doing the modem will not allow you to boot into single-user mode.

[Kofi ARTHIABAH]

Worst case scenario, you can create another file system say /var/adm/newsw ; cpio all the files from /var/adm/sw to /var/adm/newsw and then mount remove all files from /var/adm/sw and then remount /var/adm/newsw as /var/adm/sw

That should buy you some space :)

Good luck

[Denver Osborn]

regarding your lvm question about extending mirrored /var

lvm is smart enough to know not to extend the mirrored filesystem to the same physical volume. This is true as long as you have not changed the allocation policy, it should be strict but you don't need contiguous on var (as Rick said above)

# lvdisplay /dev/vg00/lvol_var
Allocation policy should be strict
As long as you have enough Free PE on the PV's that contain var and mirror copy, the lvextend should go smooth.

If you don't have the option to boot up into single user mode at the console, you could dialin and attempt to bring it down to the lowest runlevel and attempt to umount /var.

# umount /var
If device busy:
# fuser -ku /var
# fuser -ku /dev/vg00/lvol_var
# umount

If still busy you'd be better off booting up into SU mode. If you had online jfs you'd just do it on the fly.

[Denver Osborn]

Just as a note, so there aren't any "surprises" when you bring the box down to extend /var, you could do the lvextend in multi-user mode, then make time for extendfs. That way you could make sure you can lvextend to the size you need. There'd be nothing more frustrating than to bring it down and find out not enough free PE on the PV's.

Hope this helps.

[Bill Hassell]

In addition to the suggestions above, you might want to consider breaking up /var into functional areas. /var is the most critical filesystem in HP-UX as so many proceses (user and kernel) depend on using space there. Depending on what you run on your system, you might want to separate /var into:

/var/adm (logfiles)
/var/adm/crash (crash dump for kernel)
/var/mail (email)
/var/spool/lp (spool files)
/var/tmp (user temp files)
/var/adm/sw (s/ware and patches)

You can evaluate the largest directories with the command:

du -kx /var | sort -rn > /tmp/du.var

Then look at the first few lines of the resultant file. It indicates the largest directories first, a good start at picking directories to move to another disk.

[John Palmer]

Even though the box is remote, you will be able to shut it down to 'almost' single user mode from a remote telnet session with 'shutdown 0'.

If anything still has /var open at this point, you should be able to kill it off. I can't ever remember having a problem with /var - /usr yes (in use by init).

Having extended the filesystem with 'extendfs' then you can simply 'reboot'.

The suggestion for lvextending before shutting down is good as you can do this at any time.

LVM will automatically extend both mirrors and provided you only have two disks in your root volume group, the result should be as you expected. If you have more disks however then you should specify the disks to lvcreate.

You can check where the current extents are with 'lvdisplay -v /dev/vg00/lvol?'.

If for example your primary disk is c2t2d0 and your mirror c1t2d0 then your lvextend should read:-

lvextend -L /dev/vg00/lvol? /dev/dsk/c2t2d0 /dev/dsk/c1t2d0

[Scott D. Allen]

I appreciate all the fantastic suggestions. Actually, I am trying to apply a HP SW patch bundle (June 2000) to the system, which failed during the analysis phase because of not enough space on /var. That is the reason for this whole question. It didn't specify where on /var was short, but I'm suspecting from Koti's comments that I should probably just create a /var/adm/sw filesystem to handle these situations. Seem fair to everyone? Is that where swinstall puts everything? Thanks again.
--Scott

[James R. Ferguson · Accepted solution]

Scott:

Yet another way to regain precious /var space is to run the 'cleanup' utility. See: 'man 1M cleanup' to review its usage. I routinely recover very significant amounts of space from /var following installations of large patch bundles. cleanup is the safest, recommended way to manage the /var/adm/sw/patch directory on HP 10.20. On 11.X, do swmodify -x patch_commit=true .

Make sure, too, to remove remove unnecessary files in /var/tmp, /var/adm/crash, /var/preserve, etc.

...JRF...

[Scott D. Allen]

Thanks again to all who answered. I used the cleanup utility and now I have plenty of room for my patch. I will be expanding /var in the future though, as it is pretty small ~250MB and separating /var/adm/sw to a separate filesystem.

[Charles Darnell]

Thanks James! You saved us from extending 3+ boxes!