Determine single-user run-level

[Jeff_Traigle]

I'm trying to write a script to extend a logical volume. In order to assure things go smoothly (assuring no open files on the file system), the system needs to be in single-user mode. How do I check this in the script? After I reboot into single-user mode, "who -r" returns

. run-level 3 Apr 26 13:54 3 0 S

which is exactly what it returned when the system was in run-level 3. (I'm assuming this is because /var/tmp/wtmp isn't available because /var isn't mounted.)

Trying to enter single-user mode with "init s" allows "who -r" to return the correct run-level, but the system is still running all processes it was in run-level 3 so the script would fail anyway since there are open files in the file system still.

Ideas?

[doug mielke]

It appears that something is preventing you from going to single user.
who -r should correctly tell you.
init 1
might do the trick. If you can be at the console, you may see where it's stopping.

[Jeff Schussele]

Hi Jeff,

I'm afraid you're going to have trouble doing it this way for the reasons you're already seeing - not everything will be stopped.

You really have to reboot the system & stop the autoboot at the BCH> bo pri then Y to interacct w/ISL? ISL>hpux -is
That's the only sure way to do this.

Rgds,
Jeff

[G. Vrijhoeven · Accepted solution]

Hi,

Create an rc script that extends the lvol in /etc/rc1.d/SNNscript_name. and reboot the server. Just make sure all commands needed are available at the time ( NN number) the script is run, and make sure you do not have a typo.

HTH,

Gideon

[Jeff_Traigle]

Nice idea, Gideon. As long as I make sure it's the last script run at state 1, all of the local file systems will be mounted so command availability shouldn't be a problem. It certainly seems to be the most reliable option available.

[G. Vrijhoeven]

Hi Jeff,

Just make sure you remove/disable the script after completion.

Gideon

( 0 Points please)

[Jeff Schussele]

I guess the relevant question is:

What FS are you extending?

/ , /stand , primary swap are definite NO GOs.
No matter what you do because they *have* to stay contigous. Ignite tapes are the only way to do these.

/usr , /var , /opt & probably even /tmp will be problematic but might be possible.

But it seems to me to be running a big risk for what? A couple of extra minutes. You *still* have to stop everything. If you mess up an FS because of an unseen event or parameter you'll spend *much* more time recovering than you would have used going all the way to reboot.

Your call,
Jeff

[Jeff_Traigle]

The FS being extended is not OS related. It contains user home directories and our proprietary software our customers use. Hopefully, this scenario won't occur very often since typically the second disk in our systems is used for mirroring, but we do have customers with on-site systems (as opposed to the systems we have in our hosting center) that choose to extend this FS instead of mirroring. (Mostly older systems with smaller disks.) So this script *should* only come into play if we're rebuilding a system that had a disk die anyway.

[Jeff Schussele]

Well, if it's not in vg00, then you shouldn't need to go to single-user mode.
Just make sure that /etc/default/security contains NOLOGIN=1 . Then just touch /etc/nologin or better yet put some text in it like "System login prohibited at this time - maintenance in progress."
Then you can boot users off (fuser?), stop the app & umount the FS & extend it. Then just undo all this & voila - mission accomplished.
One caveat - make sure root's home dir is *not* in the same VG as the regular users if $HOME is involved here - use /root or something.

If vg00 is out of the picture - things are much, much easier.

My 2 cents,
Jeff