Understanding Run Levels
UNIX systems, as well as BSD flavors, have only two
run levels --
single user and multiple user. Under SV, run levels
have become to
a machine what permissions are to a user. Operating
at one run level
restricts a machine from performing certain tasks (such
while running at another enables these functions. Which
are enabled at each run level has changed over the years
run level 1 used to be equivalent to multi-user state
on many older
machines), but under current definitions, there are
0 -- Shutdown state requiring a manual reboot.
When you change to this level, files are synchronized
with the disk
and the system is left in a state where it is safe to
power it off.
This level is also known on some systems as "Q"
Q or q -- On systems where these are
not equal to zero, they force the system to reread the
files and take into account any changes that have occurred
1 -- Single user mode, also known as "S"
or "s" mode on many systems. This allows only
one user (traditionally
the root user) to access the system and prevents anyone
getting in. Additionally, it allows only one terminal
to login. If
the change is to level 1, then the one terminal allowed
to login is
the one defined as the console (and this command can
be given only
at the console). If the change is to S/s, then the only
to log in is the one that changed the run level. This
is the level
used when performing kernel rebuilds, installing software
the kernel, performing troubleshooting, etc.
2 -- Multiple user mode, the traditional
state allowing more than one user to login at a time.
This is the
level where background processes (daemons) startup and
file systems, if present, are mounted. (Note: the root
is always mounted.)
3 -- Network mode. This is the same as level
2, but with networking or remote file sharing enabled.
4 -- User defined.
5 -- Hardware state.
6 -- Shutdown and automatic reboot. This
performs the same action as changing to run level 0
the machine. This can be called a "warm boot"
(in the language
of the DOS world), because power is never removed from
Run levels 0 and 5 represent a "cold boot,"
since power must
be turned off and then restored.
An easy way to summarize the run levels is that 2, 3,
and 4 are operational
states of the computer -- it is up and running and users
to conduct business. All other run levels involve some
sort of maintenance
or shutdown operation that prevents users from processing.
Identifying and Changing Run Levels
The -r parameter of the who command gives you your
machine's current run level as well as the two most
run levels. For example,
$ who -r
. run level 2 May 4 10:07 2 1 0
shows that the current run level is 2 and that that
been the run level since May 4th at 10:07. The three
numbers to the
right show the current run level, the previous run level,
next previous run level on some systems. On other systems,
numbers represent the process termination status, process
process exit status.
Changing levels requires root permission and can be
done with either
the init or shutdown command. Depending upon your
vendor and system, the init utility is located in either
or /sbin. The shutdown command, is traditionally in
/usr/sbin. The init utility is very simple: it allows
you to specify a number and the machine then changes
to that run level.
# init 3
would immediately change the machine to run level 3.
The shutdown command interacts with init and offers
substantially more parameters and options. A -g option
you to specify a grace period of seconds to use before
operation (the default is 60), -i signifies which run
you want to go to, and -y carries out the action without
for additional confirmation. To change to run level
3 in 15 seconds,
the command would be:
# shutdown -g15 -i3 -y
Once the command is typed, a warning message is broadcast
telling users that the run level is changing (this is
true with init
as well). The system then waits the specified number
of seconds --
allowing users to save files and log off -- before making
By contrast, init, would tell users the run level is
and would immediately begin changing it without giving
the users time
to protect their work.
Actions Defined in inittab
The inittab file, located in /etc or /sbin,
is an initialization table. It contains a list (or table)
of the actions
that take place when a machine changes to a different
run level. Listing 1
shows a section of an inittab file from an SCO system.
line numbers to the left have been added to aid this
entry is a colon-delimited field consisting of four
id is the identification of the process, usually
only two or three letters in length -- one to four is
rstate is the required state, or run level,
necessary for the process to execute.
action is a keyword telling init what
to do with the process.
process is the actual command to be carried
Line 3 of Listing 1 is extremely important: it is the
line. In this example, each time the system is rebooted,
it will attempt
to change to an initial state of S -- single user. It
just as easily be 2 -- multi-user. The file is plain
so to make the system boot to a different level, you
can use any editor
to change this line. The inittab file is not required
the operating system to boot -- it is only a convenience.
systems, if the file is erased or damaged, the system
will boot to
single user, and any attempt to change to another state
it to hang. On other systems, if the entry or file is
a prompt will ask the console what the run level should
Line 3 of Listing 1 is the only place where the action
field is defined
as initdefault. Other actions that can be specified
boot -- The entry is processed only on bootup
and is not restarted if it dies. init does not wait
to complete running before continuing on to the next
can run many of these simultaneously. This action is
bootwait -- The entry is processed only
on bootup; init waits for it to finish running and then
before continuing. It does not restart the process once
or dies off. Line 2 of Listing 1 uses this option with
a utility to
mount and check file systems.
off -- If the process is currently running,
a warning signal is sent, and after 20 seconds the process
with a kill -9 command. Line 16 shows that when the
is changed to 2 (multiple user) terminal 1 is killed.
This has the
effect of logging that user off; it adds a level of
protects against the possibility of the root user changing
and walking away from the terminal, thus allowing access
who happens to sit there.
once -- When the specified run level is
reached, the process is started. init does not wait
process to terminate before continuing on, and does
not restart it
if it dies. Like boot, this option is not used very
ondemand -- This option has the same meaning
as respawn but is used mostly with a, b, and c levels
defined) (see respawn for more information).
powerfail -- The action is triggered only
when a power failure is at hand. A signal 19 is the
most common indication
of a power failure. A powerfail typically calls a sync
powerwait -- When a power failure occurs,
this process is run, and init waits until the processing
before processing anymore commands. Again, sync operations
main purpose of the action.
respawn -- If the process dies after it
has been started, it gets restarted. init, does not
it to complete execution before continuing on to other
lines 8-15 in Listing 1 show, respawn is associated
once a terminal is killed, you want it to respawn and
syncinit -- This option is not available
on all systems. It tells init to reset the default sync
that is, the number of seconds until modified memory
are written to the physical disk. Default time is 300
the interval can be set to anything between 15 and 900.
sysinit -- Before init tries to
access the console, it must run this entry, which is
for devices that must be initialized before run levels
Line 1 in Listing 1 shows that the Trusted Computing
Base, which is
used for user login and authentication, is initialized
the console is made active, allowing any user to log
wait -- This option starts the process
at the specified run level and causes init to wait until
process completes before moving on. This option is associated
scripts that perform the run level changes. Lines 4-7
in Listing 1
use this option for every run level change.
Line 2 of Listing 1 shows that the same processes will
out for run level changes to 2 or 3. Similarly, line
4 shows that
the same processes will be carried out for changes to
run levels 0,
5, or 6. The process carried out by line 4 is a shell
in the /etc directory called rc0.
Listing 2 shows several key routines from the rc0 script
an SCO machine. I chose to use SCO because it illustrates
steps that are carried out. I added line numbers to
the file for purposes
of this discussion, and then stipped away those lines
that were not
Lines 24 and 81 of Listing 2 work together, first saving
settings and then restoring them after completing other
Line 26 echoes that the system is coming down. Line
42 is where things
get interesting: a test is performed to see if there
is a directory
called /etc/rc0.d. If there is, then any file within
directory that begins with a "K" is executed
Next any file within that directory beginning with an
gets executed (lines 54-60). Line 74 effectively ignores
kill signal by mapping it to nothing -- theoretically,
up until this point, it is still possible to stop the
killall is performed to kill all processes with a signal
9, then three sync operations are performed. Finally,
drives are unmounted
(line 80), two more syncs are done (line 82), and a
message is echoed
that the system is down. One last sync rounds out the
change to run
Similar scripts exist under the names of rc1, rc2,
and rc3. Each performs similar operations. For example,
checks to see if there is an rc1.d subdirectory. If
is, it executes any scripts within that subdirectory
"K", that any scripts within that subdirectory
About K and S Scripts
On older systems, all executable scripts are kept in
a single directory,
with each script combining the S* and K* action (hard
links point to the relevant script). On newer systems,
within each rcx.d subdirectory that begin with a "K"
kill a process that is already running; those that begin
with an "S"
start a process that is not yet running. The names of
typically begin with the "K" or "S",
followed by a
two-digit number and a name for the operation. Listing
3 shows a listing
of the rc0.d and rc2.d subdirectories. The two digit
number has no special significance, and can fall anywhere
00 and 99. The numbers need not increment in any certain
a newly created script can take any number not already
in use within
that directory. The only thing to bear in mind is the
called for execution with "K*" and "S*";
are executed in numerical order with 00 (providing it
first and 99 executed last.
It is relatively simple to understand what most of the
since to their names are descriptive. The files displayed
in Listing 3
have the following consequences:
K00ANNOUNCE -- simply echoes "System
services are now being stopped."
K70uucp -- cleans up miscellaneous uucp
K75cron -- links to S75cron. Depending
upon which way it is called, it will either kill the
pid, or start /etc/cron the same script is capable
K80lp -- links to S80lp. It will
either summon /usr/lib/lpshut or start /usr/lib/lpsched.
If a printer lock exists (/usr/spool/lp/SCHEDLOCK),
K86mmdf -- links to S86mmdf.
Depending upon how it is called, it will either start
daemon or kill its associated pid. Like several of these
K86mmdf uses the following syntax to find the pid:
pid=`/bin/su root -c "/bin/ps -e" | grep whatever | sed -e 's/^ *//' -e 's/.*//'
S00SYSINIT -- runs additional scripts in
/etc/rc.d/0 and /etc/rc.d/1. This is used only for
historical purposes and to maintain compatibility with
S01MOUNTFSYS -- performs a mountall
to bring up the filesystems and initiate auditing.
S03RECOVERY -- provides crash recovery after
S04CLEAN -- removes temporary and lock files.
This is where /tmp gets emptied out.
S05RMTMPFILES -- cleans up any other existing
S15HWDNLOAD -- performs a hardware download.
S16KERNINIT -- performs a kernel initialization.
S20sysetup -- prints system id information,
if it exists; creates the information by sending the
output of uname
-n to /etc/systemid.
S21perf -- fires up the administrative utility
S87USRDAEMON -- starts up the user daemons.
S88USRDEFINE -- provides a location where
system specific routines can be placed.
S90RESERVED -- sets several variables, and
mails information about the boot to the root user's
You can start and stop additional processes when you
change to one
of the already defined run levels simply by creating
a shell script,
preceding it with "K" or "S", and
placing it in the
appropriate rcx.d subdirectory.
Creating a Run Level
Using the information presented here, you can easily
create your own
run level. Run level 4 is, by default, not used by the
system. As mentioned earlier, you can use it to customize
To do so follow these four steps:
1. Create an entry in /etc/inittab. It should resemble
r4:4:wait:/etc/rc4 1> /dev/console 2>&1 </dev/console
2. Create a script in /etc called rc4 by copying rc0
to rc4, then changing all references from rc0.d to
rc4.d. The only references should be as shown in Listing
on lines 42, 44, and 54. Comment out lines 26, 76-80,
82, and 85.
Then change the echo statement on line 84 to say "Change
to Run Level 4 completed."
3. Make an rc4.d subdirectory below /etc.
4. Within /etc/rc4.d create your command scripts. If,
example, you want to start a database process when you
change to this
run level, call the script S00DATABASE, and place the
to start it within that script. Then create a corresponding
script to close the database when you change from that
Several files maintain run level information. /etc/default/boot
is an SCO-specific file that maintains information on
keyboard. /etc/wtmp and /etc/utmp work as opposite
log files to each other. /etc/wtmp keeps a record of
that are spawned, while /etc/utmp keeps a record of
that have died. These log files do tend to grow and
should be routinely
Changing run levels simply entails calling an additional
set of scripts.
Those scripts can either start processes that are not
running or kill
processes that are. Run levels 2 and 3 are operational
users to interact with the operating system. Run levels
0, 1, 5, and
6 involve downing the computer or performing maintenance
Run level 4 is available for administrator definition
and can easily
be used to stop and start additional processes.
About the Author
Emmett Dulaney is a product developer for New Riders
co-author of Inside TCP/IP. He can be reached on CompuServe