UNIX System Administration Handbook - Evi Nemeth [26]
The SystemV init defines 7 “run levels,” each of which represents a particular complement of services that the system should be running:
• Level 0 is the level in which the system is completely shut down.
• Level 1 or S represents single-user mode.
• Levels 2 through 5 are multiuser levels.
• Level 6 is a “reboot” level.
Levels 0 and 6 are special in that the system can’t actually remain in them; it shuts down or reboots as a side effect of entering them. On most systems, the normal multiuser run level is 2 or 3. Run levels 4 and 5 are rarely used, and run levels 1 and S are different on each system.
Single-user mode was traditionally init level 1. It brought down all multiuser and remote login processes and made sure the system was running a minimal complement of software. Since single-user mode provides root access to the system, however, administrators wanted the system to prompt for the root password whenever it was booted into single-user mode. The S run level was created to address this need: it spawns a process that prompts for the root password. On Solaris, S is the “real” single-user run level, but on Linux, it serves only to prompt for the root password and is not a destination in itself.
There seem to be more run levels defined than are strictly necessary or useful. The usual explanation for this is that a phone switch had 7 run levels, so it was thought that a UNIX system should have at least that many. Red Hat actually supports up to 10 run levels, but levels 7 through 9 are undefined.
The /etc/inittab file tells init what to do at each of its run levels. Its format varies from system to system, but the basic idea is that inittab defines commands that are to be run (or kept running) when the system enters each level.
As the machine boots, init ratchets its way up from run level 0 to the default run level set in /etc/inittab. To accomplish the transition between each pair of adjacent run levels, init runs the actions spelled out for that transition in /etc/inittab. The same progression is made in reverse order when the machine is shut down.
Unfortunately, the semantics of the inittab file are fairly crude, and they don’t mesh well with the way that services are actually started and stopped on UNIX systems. To map the facilities of the inittab file into something a bit more usable, descendants of SystemV implement an additional layer of abstraction. This layer usually takes the form of a “change run levels” command that’s run out of inittab. It executes scripts from a run-level-dependent directory to bring the system to its new state.
It’s usually not necessary for system administrators to deal directly with /etc/inittab because the script-based interface is adequate for almost any application. In the remainder of this chapter, we will tacitly ignore the inittab file and the other glue that attaches init to the execution of startup scripts. Just keep in mind that when we say that init runs such-and-such a script, the connection may not be quite so direct.
The master copies of the startup scripts live in a directory called init.d. The init.d directory is usually in /etc, but that is not always the case. Each script is responsible for one daemon or one particular aspect of the system. The scripts understand the arguments start and stop to mean that the service they deal with should be initialized or halted. Most also understand restart, which is typically the same as a stop followed by a start. As a system administrator, you can manually start and stop individual services by running the associated init.d script with an appropriate argument.
For example, here’s a simple startup script that can start, stop, or restart sshd:
#! /bin/sh
test -f /usr/local/sbin/sshd || exit 0
case "$1" in
start)
echo -n "Starting sshd: sshd"
/usr/local/sbin/sshd
echo "."
;;
stop)
echo -n "Stopping sshd: sshd"
kill `cat /var/run/sshd.pid`
echo