topic Re: /var filesystem in Operating System - HP-UX

/var filesystem

Scott D. Allen — Fri, 08 Sep 2000 20:00:36 GMT

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

Re: /var filesystem

Rick Garland — Fri, 08 Sep 2000 20:15:40 GMT

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.

Re: /var filesystem

Patrick Wallek — Fri, 08 Sep 2000 20:19:38 GMT

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.

Re: /var filesystem

Kofi ARTHIABAH — Fri, 08 Sep 2000 20:22:28 GMT

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.

Re: /var filesystem

Scott D. Allen — Fri, 08 Sep 2000 20:26:47 GMT

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

Re: /var filesystem

Rick Garland — Fri, 08 Sep 2000 20:51:14 GMT

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.

Re: /var filesystem

Rick Garland — Fri, 08 Sep 2000 20:51:43 GMT

Re: /var filesystem

Kofi ARTHIABAH — Fri, 08 Sep 2000 20:58:31 GMT

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

Re: /var filesystem

Denver Osborn — Fri, 08 Sep 2000 21:05:55 GMT

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.

Re: /var filesystem

Denver Osborn — Fri, 08 Sep 2000 21:12:41 GMT

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.

Re: /var filesystem

Bill Hassell — Fri, 08 Sep 2000 21:22:27 GMT

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.

Re: /var filesystem

John Palmer — Fri, 08 Sep 2000 21:55:39 GMT

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

Re: /var filesystem

Scott D. Allen — Mon, 11 Sep 2000 13:35:04 GMT

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

Re: /var filesystem

James R. Ferguson — Mon, 11 Sep 2000 13:42:40 GMT

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

Re: /var filesystem

Scott D. Allen — Mon, 11 Sep 2000 13:56:23 GMT

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.

Re: /var filesystem

Charles Darnell — Fri, 09 Mar 2001 19:51:50 GMT

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