The process differs greatly on System V systems, where there can be many different run levels. The run levels available under SCO OpenServer 5.0 are shown in table 2.5.
Table 2.5 SCO OpenServer 5.0 Run Levels
Run Level
Explanation
0
Shuts down the machine so that the power can be removed safely. Has the machine remove power if it can. This state can be executed only from the console.
1
Puts the system in single-user mode. Unmounts all file systems except the root file system. All user processes are killed except those connected to the console. This state can be executed only from the console.
2
Puts the system in multiuser mode. All multiuser environment terminal processes and daemons are spawned. This state is commonly referred to as multiuser mode.
3, 4
These run levels, while being multiuser also, can be customized by the administrator to offer additional services. They are not necessary for system operation and are not normally used.
5
Stops the Unix system and goes to the firmware monitor.
6
Stops the Unix system and reboots to the run-level defined by the initdefault entry in /etc/inittab.
a, b, c
Processes only those /etc/inittab entries having the a, b, or c run-level set. These are pseudo-states that may be defined to run certain commands, but do not cause the current run-level to change.
q, Q
Re-examines /etc/inittab.
s, S
Enters single-user mode. When this occurs, the terminal that executed this command becomes the system console. This is the only run-level that doesn’t require the existence of a properly formatted /etc/inittab file. If this file does not exist, then by default the only legal run-level that init can enter is the single-user mode. When the system enters S or s, all mounted file systems remain mounted and only processes spawned by init are killed.
As is evident, the differences in the services available with the different run levels are extensive. For most Unix systems, however, networking and non-root file systems are generally only available when operating in multiuser mode.
To switch run levels in the System V universe, run the command init, or telinit with the new run level. Afterward, the system prints the new run level information on the console and starts the process of switching to the new run level. To switch, the system reads the /etc/inittab file and executes commands that have the same run level. The /etc/inittab file consists of colon delimited records:
These fields consist of a unique identifier for the record, the run levels that this item is to be processed for, the action (what is to be done), and the command to be executed. init processes this file when it enters the given run level. The action field can consist of the following:
•boot. The entry is to be processed only at init’s boot-time read of the inittab file. init is to start the process, not wait for its termination; and when it dies, not restart the process. For this instruction to be meaningful, the run level should be the default or it must match init’s run-level at boot time. This action is useful for an initialization function following a hardware reboot of the system.
•bootwait. The entry is to be processed the first time init goes from single-user to multi-user state after the system is booted. (If the value of initdefault is set to 2, the process will run right after the boot.) init starts the process, waits for its termination and, when it dies, does not restart the process.
•initdefault. An entry with this action is only scanned when init is first started. init uses this entry, if it exists, to determine which run level to enter first. It does this by taking the highest run level specified in the run level field and using that as its initial level. If the run level field is empty, it is interpreted as 0123456, which causes init to enter run level 6. If init does not find an initdefault entry in /etc/inittab, it will request an initial run level from the user at reboot time.
•off. If the process associated with this entry is currently running, send the warning signal (SIGTERM) and wait 20 seconds before forcibly terminating the process via the kill signal (SIGKILL). If the process is nonexistent, ignore the entry.
•once. When init enters a run level that matches the entry’s run level, init is to start the process and not wait for its termination. When it dies, do not restart the process. If upon entering a new run level, when the process is still running from a previous run level change, the program will not be restarted.
•ondemand. This instruction is really a synonym for the respawn action. It is functionally identical to respawn but is given a different keyword to separate it from run levels. This is used only with the a, b, or c values described in the run level field.
•powerfail. Execute the process associated with this entry only when init receives a power fail signal.
•powerwait. Execute the process associated with this entry only when init receives a power fail signal, but wait until it terminates before continuing any processing of inittab.
•respawn. If the process does not exist, then start the process; do not wait for its termination (continue scanning the inittab file). When the process dies, restart the process. If the process currently exists, then do nothing and continue scanning the inittab file.
•sysinit. init executes these entries when the system first goes to single-user mode after being rebooted. It does not execute these entries if the system is subsequently put in single-user mode from any run-level 1 through 6. Entries with sysinit in their action field do not specify a run level in their run level field.
•wait. When init enters the run level that matches the entry’s run level, start the process and wait for its termination. All subsequent reads of the inittab file while init is in the same run level will cause init to ignore this entry.
