Hey there,
Today's post hearkens back to an earlier time, when I was administrating Solaris 2.4 and figured Sun had big plans for run level 4. It was, after all "reserved for future use." I don't know about you, but (to this day) when I see terminology like that, I tend to shy away from getting too comfortable with working in a cheap hack. My thinking was that, at some point (given Sun's policy at the time) they'd come up with a unique use for run level 4 and I'd have a whole lot of stuff set up to launch from there and my world would be thrown into chaos ;)
I no longer worry too much about the chaos (something, somewhere is going to break or I'll eventually be out of a job ;), but I still like to keep tabs on Solaris' "level 4" status updates and their command run-level policies. So, today, we'll take a brief look at "run level 4" and then look at a few commands, used to change run levels, that may not act as you would expect.
1. Run level 4: It is still, technically, reserved for future use on Solaris. However, the subtle difference in meaning over time has been stated more clearly with the last few releases. Now, about half of the places you look (on Sun's Documentation Site) list "run level 4" as being "user-defined." What this means, aside from the fact that any admin can make use of it if he or she deems it worthwhile, is that I spent a lot of time worrying about nothing. Of course, I'm willing to forgive, since I never had any use for "run level 4" anyway.
On most Linux and Unix distro's, run level 4 is considered open and user-definable. In a few instances, on HP-UX and Slakware, among others, run level 4 is the default run level for the X-Windows display manager. Generally, this is found on run level 5. But, before I go crazy over-explaining, check out Wikipedia's entry on run levels for virtually every system known to man :)
The only thing you have to make sure of, for the most part, if you want to use Solaris' run level 4 is that you create an entry for it in /etc/inittab. Something like:
s4:4:wait:/sbin/rc4 >/dev/msglog 2<>/dev/msglog </dev/console
would probably suffice for distributions up to, and including Solaris 9. If there are minor differences in your distribution, you can simply copy the line for "s3," paste it below and change all the 3's to 4's. Fairly simplistic, but without it, Solaris' init will never know to look there and will not know what you mean when you try to change to run level 4.
On Solaris 10, things are a little goofier, but in a good way. You can mess around with the inittab and set things up that way, but if you use the "out-of-the-box" configuration and stick with the Service Management Facility (SMF), you won't need to worry about that. SMF has no concept of run levels and doesn't need /etc/inittab. Since SMF handles the order of starting services (with dependencies), you don't need to have a "separate" run level to accomplish whatever end you were shooting for. You can add new services with SMF and then goof around, to your heart's content, with svcadm, svccfg, svc.configd, etc. You may find yourself longing for the "old ways" until you get used to it.
2. Some command run level changing commands and what they're limited to: Some of this stuff still surprises me, since it seems counter-intuitive, but I guess I've always been lucky in the way I start stuff up and shut it down (my apologies to Clint Eastwood for bastardizing his famous quote from "Unforgiven" ;) Plus, I'm a big fan of "init" :) We're going to forget run level 4 exists for most of this part since it rarely matters... technically...
a. init: This command can be used to bring Solaris to any run level you specify (0, 1, s, S, 2, 3, 4, 5 and 6). This is a bone of contention, if you ever have to get certified, but Sun says there are only 8 run levels, of which only 7 are used. If you count "s" and "S" as separate (even though they both do the same thing) I would back you up if your answer was 9.
b. reboot: This command can only bring the system to run level 6. However, you can make reboot take you to other places by terminating the getopts routine and adding a flag afterward, so that:
host # reboot -- -s
would allow you to use the reboot command to get into single user mode. Also, another reason this perplexes me as much as it does is that, technically, bringing the machine to run level 6 entails the system going through a series of run levels leading all the way to the default run level (which is 3, if you left it alone). Sun's answer is technically true, but somewhat misleading. The only thing you really "can't" do with reboot is stop at run levels 0, 1, 2 and 5 (unless you make one of them your default run level in /etc/inittab - not a good idea, especially for 0 and 5 ;)
c. shutdown: This command can only bring the system to run levels 0, 1, s/S, 5 or 6. This makes sense to a degree, since run level 6 is reboot, 5 is power-off and 0 is PROM. I don't understand why it can shut the system down to run level 1 (single user with all local filesystems mounted read-write) and s/S (single user with only / mounted read-only) and not shut it down to run level 2 (basic multi-user with network) from run level 3 (same multi-user with nfs and some additional network services) straight up. As noted above, regarding reboot, you can actually make this command take you to any run level except 2 (unless you set that as your default run level in /etc/inittab)
d. poweroff: This command can only bring the system to run level 5. Perfectly sensible.
e. halt: This command can only bring the system to run level 0. This makes sense, too.
f. uadmin: This command can only bring the system to run levels 0, 5 and 6 (see above regarding why run level 6 means you can also use this command to get to run level 3, or your system default run level, as well). This command is restricted to super-user access by default. For the longest time I thought it could get you to any run level straight off, although I never needed to use it except to dump the system. An interesting fact about uadmin is that it can accept arguments. Which means, if you're feeling moderately clever, you can make it go places Mother won't let it go, by fudging it a little. Consider the following, understanding that uadmin converts arguments into integers as such, and is invoked as "uadmin command function optarg":
commands:
1 = No Disk Sync
2 = Sync Disks
functions:
1 = A_REBOOT <-- Run level 6
2 = A_SHUTDOWN <-- Run level 0
5 = A_DUMP <-- Run level 5
optional arguments:
Try whatever you want out, if you can afford to. Be sure to enclose an argument with spaces in double quotes.
host # uadmin 1 1 "-s kernel/unix" <-- Basically any option you can pass to the PROM "boot" command, you can sneak in here!
also, there are multiple versions of uadmin available, depending on your Solaris release, so you may be looking at these set of options, which will get you to run levels 0, s/S, 1, 2, 5 and 6 (which gives you run level 3) as well as allowing you the optional argument:
uadmin 2 0: sync the filesystems and drops system to ok prompt
uadmin 2 1: sync the filesystems and reboots to multi-user mode
uadmin 2 2: sync the filesystems and reboots interactively
uadmin 2 3: sync the filesystems and reboots to single-user mode
uadmin 2 6: sync the filesystems and powers off the system
uadmin 1 0: do not sync filesystems and drops system to ok prompt
uadmin 1 1: do not sync filesystems and reboots to multi-user mode
uadmin 1 2: do not sync filesystems and reboots interactively
uadmin 1 3: do not sync filesystems and reboots to single-user mode
uadmin 1 6: do not sync filesystems and powers off the system
Now, let's kick back and let the raging debate about OS version-and-release accuracy begin ;)
Cheers,
, Mike
Please note that this blog accepts comments via
email only. See our
Mission And Policy Statement for further details.
