The boot process is described in detail at Gustavo Duarte's "The Kernel Boot Process"

What's important to understand is that the kernel's init_post() function is the final step in the boot process. It tries to execute the first user-mode process in the following order:

If none of these succeed, the kernel will panic.

As mentioned earlier, init reads the file /etc/inittab to determine what it should do. An entry in this file has the following format:

id:runlevels:action:process

Included below is an example /etc/inittab file.

# The default runlevel.
id:2:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fall through in case of emergency.
z6:6:respawn:/sbin/sulogin

# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
          

For each of the runlevels 0-6 there is an entry in /etc/inittab that executes /etc/init.d/rc ? where “?” is 0-6, as you can see in following line from the earlier example above:

l2:2:wait:/etc/init.d/rc 2
          

So, what actually happens is that /etc/init.d/rc is called with the runlevel as a parameter.

The directory /etc contains several, runlevel specific, directories which in their turn contain runlevel specific symbolic links to scripts in /etc/init.d/. Those directories are:

$ ls -d /etc/rc*
/etc/rc.boot  /etc/rc1.d  /etc/rc3.d  /etc/rc5.d  /etc/rcS.d
/etc/rc0.d    /etc/rc2.d  /etc/rc4.d  /etc/rc6.d
          

As you can see, there also is a /etc/rc.boot directory. This directory is obsolete and has been replaced by the directory /etc/rcS.d. At boot time, the directory /etc/rcS.d is scanned first and then, for backwards compatibility, the /etc/rc.boot.

The name of the symbolic link either starts with an “S” or with a “K”. Let's examine the /etc/rc2.d directory:

$ ls /etc/rc2.d
K20gpm       S11pcmcia   S20logoutd  S20ssh      S89cron
S10ipchains  S12kerneld  S20lpd      S20xfs      S91apache
S10sysklogd  S14ppp      S20makedev  S22ntpdate  S99gdm
S11klogd     S20inetd    S20mysql    S89atd      S99rmnologin
          

If the name of the symbolic link starts with a “K”, the script is called with “stop” as a parameter to stop the process. This is the case for K20gpm, so the command becomes K20gpm stop. Let's find out what program or script is called:

$ ls -l /etc/rc2.d/K20gpm
lrwxrwxrwx 1 root root 13 Mar 23 2001 /etc/rc2.d/K20gpm -> ../init.d/gpm
          

So, K20gpm stop results in /etc/init.d/gpm stop. Let's see what happens with the “stop” parameter by examining part of the script:

#!/bin/sh
#
# Start Mouse event server
...
case "$1" in
  start)
     gpm_start
     ;;
  stop)
     gpm_stop
     ;;
  force-reload|restart)
     gpm_stop
     sleep 3
     gpm_start
     ;;
  *)
     echo "Usage: /etc/init.d/gpm {start|stop|restart|force-reload}"
     exit 1
esac
          

In the case..esac the first parameter, $1, is examined and in case its value is “stop”, gpm_stop is executed.

On the other hand, if the name of the symbolic link starts with an “S”, the script is called with “start” as a parameter to start the process.

The scripts are executed in a lexical sort order of the filenames.

Let's say we've got a daemon SomeDaemon, an accompanying script /etc/init.d/SDscript and we want SomeDaemon to be running when the system is in runlevel 2 but not when the system is in runlevel 3.

As you've read earlier, this means that we need a symbolic link, starting with an “S”, for runlevel 2 and a symbolic link, starting with a “K”, for runlevel 3. We've also determined that the daemon SomeDaemon is to be started after S19someotherdaemon which implicates S20 and K80 since starting/stopping is symmetrical, i.e. that what is started first is stopped last. This is accomplished with the following set of commands:

# cd /etc/rc2.d
# ln -s ../init.d/SDscript S20SomeDaemon
# cd /etc/rc3.d
# ln -s ../init.d/SDscript K80SomeDaemon
          

Should you wish to manually start, restart or stop a process, it is good practice to use the appropriate script in /etc/init.d/ , e.g. /etc/init.d/gpm restart to initiate the restart of the process.

Changing runlevels on a running machine requires comparison of the services running in the current runlevel with those that need to run in the new runlevel. Subsequently probably some processes need to be stopped and others to be started.

Recall that the initscripts for a runlevel “X” are grouped in directory /etc/rc.d/rcX.d (or, on newer (LSB based) systems, in /etc/init.d/rcX.d). Their names there determine how the scripts are called: if the name starts with a “K”, the script will be run with the stop, if the name starts with a “S”, the script will be run with the stop option. The normal procedure during a runlevel change is to stop the superfluous processes first and then start the new ones.

The actual init scripts are located in /etc/init.d. The files you find in in the rcX.d directory are symbolic links which link to these. In many cases, the start- and stop-scripts are symbolic links to the same script. This implies that such init scripts should be able to handle at least the start and stop options.

For example, the symbolic link named S06syslog in /etc/init.d/rc3.d might point to the script /etc/init.d/syslog, as may the symbolic link found in /etc/init.d/rc2.d, named K17syslog.

The order in which services are stopped or started can be of great importance. Some services may be started simultaneously, others need to start in a strict order. For example your network needs to be up before you can start the httpd. The order is determined by the names of the symbolic links. The naming conventions dictate that the names of init scripts (the ones found in the rcN.d directories) include two digits, just after the initial letter. They are executed in alphabetical order.

In the early days system administrators created these links by hand. Later most Linux distributors decided to provide Linux commands/scripts which allow the administrator to disable or enable certain scripts in certain runlevels and to check which systems (commands) would be started in which runlevel. These commands typically will manage both the aforementioned links and will name these in such a way that the scripts are run in the proper order.

Another tool to manage the proper linking of start up (init) scripts is chckconfig. On some systems (e.g. SuSE/Novell) it serves as a front-end for insserv and uses the LSB standardized comment block to maintain its administration. On older systems it maintains its own special comment section, that has a much simpler and less flexible syntax. This older syntax consists of two lines, one of them is a description of the service, it starts with the keyword description:). The other line starts with the keyword chkconfig:, and lists the run levels for which to start the service and the priority (which determines in what order the scripts will be run while changing runlevels). For example:

# Init script for foo daemon
#
# description: food, the foo daemon
# chkconfig: 2345 55 25
#
#

This denotes that the foo daemon will start in runlevels 2, 3, 4 and 5, will have priority 55 in the queue of initscripts that are run during startup and priority 25 in the queue of initscripts that are run if the daemon needs to be stopped.

The chkconfig utility can be used to list which services will be started in which runlevels, to add or delete a service to or from a runlevel and to add or delete an entire service from the startup scripts.

chkconfig does not automatically disable or enable a service immediately, but simply changes the symbolic links. If the cron daemon is running and you are on a Red Hat based system which is running in runlevel 2, the command

 
# chkconfig --levels 2345 crond off

would change the administration but would not stop the cron daemon immediately. Also note that on a Red Hat system it is possible to specify more than one runlevel, as we did in our previous example. On Novell/SuSE systems, you may use:

 
# chkconfig food 2345

and to change this so it only will run in runlevel 1 simply use

 
# chkconfig food 1

# chkconfig --list 

will list the current status of services and the runlevels in which they are active. For example, the following two lines may be part of the output:

xdm                       0:off   1:off   2:off   3:off   4:off   5:on    6:off   
xfs                       0:off   1:off   2:off   3:off   4:off   5:off   6:off   

They indicate that the xfs service is not started in any runlevel and the xdm service only will be started while switching to runlevel 5.

To add a new service, let's say the foo daemon, we create a new init script and name it after the service, in this case we might use food. This script is consequently put into the /etc/init.d directory, we need to insert the proper header in that script (either the old chkconfig header, or the newer LSB compliant header) and run

# chkconfig --add food 

To remove the foo service from all runlevels, you may type:

# chkconfig --del food

Note, that the food script will remain in the /etc/init.d/ directory.

This command has identical functionality as the LSB command start_daemon. It starts a process if it is not already running. One of its arguments is the full path to an executable. startproc will check if there already is a process running from that executable. If not, it will start a new process by executing the executable. There are options to set the user- and groupname (-u, -g) under which the new proces should be run, the nice (-n) level and the -f option to force execution even if there seems to be another process running from the same executable.

By default, the command checks for a pidfile /var/run/<basename>.pid, but that name can be overridden by specifying the -p option. If such a pidfile exists, it is read and the command limits itself to verification of the process with that pid. If no matching process could be found, the process will be started. It is up to that process to create, delete or update the pidfile.

startproc will refuse to start up a process (unless forced by setting the -f flag) if it finds a matching zombie process in the process table.

checkproc checks if a process is running. One of its arguments is the full path to an executable. checkproc will check if there already is a process running from that executable. If so it exits with exitcode 0. If not, it will return nothing and exit with exit code 1. If the -v flag has been specified, the command will report the pids of any matching running processes it finds.

By default, the command checks for a pidfile /var/run/<basename>.pid, but that name can be overridden by specifying the -p option. If such a pidfile exists, it is read and the command limits itself to verification of the process with that pid.

killproc is used to signal running process(es). This is mostly used to stop these processes. It allows the signal to send to be specified but defaults to SIGTERM. If SIGTERM is used and the process does not terminate within five seconds a SIGKILL is sent to it. The time between sending these signals can be tuned using the -t option. If a process has been terminated and a verified pid file was found, this pid file will be removed. killproc will try to prevent killing itself, its parents or grandparents.