7.1. Introduction
There are a lot of ways to start and
stop a Linux system. Plus, there are
initialization scripts for controlling
how various services start up, and there are different system
runlevels, each of which can run a different set of services. Run
this command:
$ ps axfl
Take a look at the top, at process number 1 (this is slimmed-down;
yours will show more columns and lines):
UID PID PPID STAT TTY TIME COMMAND
0 1 0 S ? 0:03 init
That's
init,
the grandmother of all processes on a Linux system. Notice that the
ppid,
or parent process ID, is zero, because init is
the first process started after the kernel runs.
But why doesn't ps afxl show
init as the root of the process tree? The
ppids tell the story:
UID PID PPID STAT TTY TIME COMMAND
0 1 0 S ? 0:03 init
0 2 1 SW ? 0:00 [keventd]
0 0 1 SWN ? 0:00 [ksoftirqd_CPU0]
0 0 1 SW ? 0:00 [kswapd]
0 10 1 SW ? 0:00 [kreiserfsd]
0 101 1 SW ? 0:00 [kapmd]
1 274 1 S ? 0:00 /sbin/portmap
0 360 1 S ? 0:00 /sbin/syslogd
0 376 1 S ? 0:00 /usr/sbin/slapd
0 387 376 S ? 0:00 \_ /usr/sbin/slapd
0 388 387 S ? 0:00 \_ /usr/sbin/slapd
0 389 1 S ? 0:00 /usr/sbin/cupsd
The Linux boot process goes something like
this:
The system BIOS initializes hardware, then loads the boot sector. The master boot record (MBR) loads the
bootloader, which points the way to the kernel. The kernel initializes peripheral devices, loads drivers, and mounts
the root filesystem, then calls /sbin/init. /sbin/init is the master startup program that
spawns all user-level processes. It reads
/etc/inittab, then it moves on to activate yet
more scripts, which are named in /etc/inittab. Now it gets distribution-specific. On
Debian,
the next script in line is /etc/init.d/rcS,
which then hands off to whatever /etc/rc*.d
directory is specified in /etc/inittab. The
Debian default is runlevel 2, so /etc/rc2.d is
used, and all the scripts in /etc/rc2.d are
executed. This is the SysV style of startup. On Red
Hat, /etc/rc.d/rc.sysinit comes next, then the
scripts in the default runlevel directory (usually
/etc/rc3.d or /etc/rc5.d). Slackware
does it a little differently. It's more akin to the
BSD style of system startup, which has a single
/etc/rc.d/ directory with an
init script for each runlevel, though it
incorporates some SysV features as well.
On Red Hat and Debian systems, the /etc/rc*.d
directories do not contain the actual startup scripts, but rather
symlinks to scripts
in /etc/init.d. By linking to a master script
directory, /etc/init.d, unnecessary duplication
is avoided. And, in a master stroke of sheer ingenuity, the way the
symlinks are named determines how the
services
will run. For example, consider:
$ ls -go S20cupsys
lrwxrwxrwx 1 16 Sep 9 17:51 S20cupsys -> ../init.d/cupsys
S20 means the service
cupsys is to be started with a priority level of
20. Lower numbers equal higher priority. If it were
K20cupsys, that would mean the service is to be
killed. (The Linux world is harsh.) This is a simple way to ensure
that services are stopped and started the way you want, and in the
right order.
7.1.1 Runlevels
This
is the common
Linux
runlevel scheme:
- 0
-
Halt
- 1
-
Single user
- 2-5
-
Multiuser
- 6
-
Reboot
These
are the runlevels in Debian distributions:
- 0
-
Halt the system
- 1
-
Single user
- 2-5
Multiuser mode (the defaults are all the same)
- 6
-
Reboot
The
runlevels in Red Hat distributions are:
- 0
-
Halt the system
- 1
-
Single-user text mode
- 2
-
Not used (user-definable)
- 3
-
Multiuser text mode
- 4
-
Not used (user-definable)
- 5
-
Multi-user graphical mode
- 6
-
Reboot
The runlevels in
Slackware
distributions are:
- 0
-
Halt the system
- 1
-
Single-user mode
- 2
-
Unused, same as 3
- 3
-
Multiuser text mode
- 4
-
Multiuser graphical mode
- 5
-
Unused, same as 3
- 6
-
Reboot
There may be even more variations in other distributions, and
theoretically runlevels 7-9 exist, though they are not used.
It's easy enough to see what each runlevel
does—simply read the rc*.d directories.
|
