System initialization

When a computer is turned on, many things happen even before an operating system starts. The basic steps that occur each time you start a Linux system are the following:

Boot hardware – Based on information in the computer's CMOS, your computer checks and starts up the hardware. In particular, this information tells the computer which devices to check while looking for the bootable OS.
Start boot loader – once a bootable device is found, the BIOS checks the MBR (Master Boot Record) to see what to load next. With a Linux version installed, in most cases it's the GRUB boot loader. This boot loader allows the user to choose to boot Linux versions or another OS installed.
Boot the kernel – if you decided to boot Linux, the kernel is loaded. That kernel mounts the basic file systems and transfers control to the unit process.

Starting `init`

In the booting process, the transfer from the kernel phase to init is indicated by the following lines (see red lines)

The actions of the init program (full path is /sbin/init) are directed by the /etc/inittab file, which looks like

#
# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
#
# Author:       Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
#               Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
# 
id:5:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.  
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"


# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

All non-commented lines in the inittab consists of several colon-separated fields in the format:

id:runlevels:action:command

ID. The id field is a unique identifier, one to four alphanumeric characters in length, that represents a particular action to take during system startup.

Run Level. The runlevels field contains a list of runlevels in which the command will be run.

Possible Run Levels
Run Level	What happens in this run level
0	All processes are terminated and the machine comes to an orderly halt. As the `inittab` comments point out, this is NOT a good choice for `initdefault` because as soon as the kernel, modules, and drives are loaded, the machine halts.
1, s, S	This is a single-user mode, frequently used for system maintenance and instances where it may be preferable to have few processes running and no services activated. In single-user mode, the network is nonexistent, the X-server is not running, and it is possible that some file systems are not mounted.
2	Multiuser mode. Multiple logins are allowed, all configured file systems are mounted, and all processes except X, the `at` daemon, the `xinetd` daemon, and NIS/NFS are started. If your machine doesn't have a permanent network connection, this is good choice for `initdefault`.
3	Multiuser mode with network services. Run level 3 is the typical value for `initdefault` on Fedora or RHEL server.
4	Run level 4 is available as a user-defined run level. It is nearly identical to runlevel 3 in a default Fedora or RHEL configuration.
5	Multiuser mode with network services and X. This run level starts the X server and presents a graphical login window, visually resembling any of the more expensive Unix-based workstations. This is a common `initdefault` value for a Fedora or RHEL workstation or desktop systems.
6	All processes are terminated and the machine is gracefully rebooted. Again, it's not a good idea to use this as `initdefault` value. The effect is a possibly infinite cycle of booting, followed by rebooting.
7, 8, 9	Generally unused and undefined, these run levels have the potential to meet any needs not covered by the default options.
a, b, c, A, B, C	Used in conjunction with the `ondemand` action. These don't really specify a run level but can launch a program or daemon "on demand" if so instructed.

The action field represents type of the action to be taken by init. Some of the valid init actions are
- sysinit – The process will be executed during system boot. It will be executed before any boot or bootwait entries. The runlevels field is ignored.
- wait – The process will be started once when the specified runlevel is entered and init will wait for its termination.
- ctrlaltdel –This process is executed when init receives the SIGINT signal. This means someone on the system console has pressed the "CTRL-ALT-DEL" key combination.
- powerfail – Same as powerwait but init does not wait for the process to complete.
- powerokwait – The process will be executed when init receives the SIGPWR signal provided there is a file called "/etc/powerstatus" containing the word "OK". This means that the power has come back again
- respawn – The process will be restarted whenever it terminates.
- once – The process will be executed once when the specified runlevel is entered
And the complete list of these actions can be found in documentation.

System startup and shutdown

During system startup, a series of scripts are run to start the services that you need. These include scripts to start network interfaces, mount directoreis, and monitor your system.Most of these scripts are run from the subdirectoreis of /etc/rc.d. The program that starts most of these services up when you boot and stops them when you shut down is the /etc/rc.d/rc script.

Shortly, the /etc/rc.d/rc script does the following

Checks that run-level scripts are correct – The rc script checks to find each run-level script that exists and excludes those that represent backup scripts left by rpm updates.
Determines current and previous run levels to know which run-level scripts to stop (previous run-level) and start (current run-level).
Decides whether to enter interactive startup – If the confirm option is passed to the boot loader at the boot time, all server processes must be confirmed at the system console before starting.
Kills and starts run-level scripts – stops run-level scripts from the previous level and starts run-level scripts from the current level.

Typical location for scripts that start/stop services of software packages is /etc/init.d directory (which actually is a shortcut to /etc/rc.d/init.d).

Each script representing a service that you want to start or stop is linked to a file in each of the run-level directories. The run-level sub-directors with names rc#.d where # represents a number from 0 to 6. These run-levels sub-dirs contain files with the names like S95atd or K15httpd.

For each run-level, a script beginning with K (for Kill) stops the service, whereas a script beginning with S (for Start) stars the service. In fact, these scripts are nothing but symbolic links (see ln command) to the real start/stop service scripts from /etc/init.d directory. The two digits after the first letter in the script name (either S or K) provide a mechanism to select the priority in which the program are run. The rc script sorts all the scripts from the appropriate run-level alphabetically and the runs them one by one in this order. In particular, this means that S10network is run before S90crond. However, this also means that S110my_daemon will be run before S90crond.

If you need to reorganize or remove run-level scripts, you have several options. You can use GUI Service Configuration from the System / Administration / Services (or just run system-config-services from shell). You can also use a console interface program ntsysv that basically provides the same functionality.

You can also use the pure command line tool chkconfig. Being used with the option --list this program provides information about the run-levels for all scripts or a particular script (given as a parameter):

$ /sbin/chkconfig --list sshd
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

The output shows that sshd daemon is configured to run on levels 2, 3, 4, and 5.

Using the chkconfig command you also can add your own service to the list of services run at startup. This is done with a simple chkcondig --add command providing the name of the script that starts your service as the second argument:

$ chkconfig --add my_daemon

But first you have to make sure that your script satisfies several conditions:

it has to be copied to /etc/init.d directory
it has to recognize arguments start, stop, and restart and take appropriate actions
and finally, inside the script code it should have some instructions for the chkconfig command. These instructions look like the following lines:
```
  # chkconfig: 345 82 28
  # description: This scripts starts MY_DAEMON service
  # processname: my_daemon
  
```
The most important out of these three line is, of course, the first line. The line chkconfig: 345 82 28 sets the service to be started on levels 3, 4, and 5 (parameter 345), give the S-script number 82, and give the K-scripts number 28. Thus, in the directories /etc/rc.d/rc3.d, /etc/rc.d/rc4.d, and /etc/rc.d/rc4.d the file S82my_daemon will be created, and all other run-level directories will contain K28my_daemon file.

Changing the run-level

If you logged in as the root user, you can change easily determine the current run-level by using the runlevel command:

$ runlevel
N 5

The output of this command consists of two values. The first one (in the example above it's N) reports the previous run level, whereas the second one (5) tells you the current one.

If you would like to change the current runlevel, you can do this by using either init or telinit command (both located at the /sbin directory.) For example, the init 3 command changes the run-level to level 3.

As a matter of fact, shutting down or rebooting the machine is nothing but changing the run-level. For example, init 0 will shut the system down, while the init 6 command will reboot it. With this in mind, other ways to change the run-level include the reboot, halt, poweroff, and shutdown commands. Please read the manual pages for these commands and discover that they all in fact just one program.

Managing `xinetd` services

There are a bunch of services, particularly network services, which are not handled by separate run-level scripts. Instead, a single run-level script called xinetd is run to handle incoming requests for these services. For that reason, xinetd is sometime referred to as the super-server.

When a request comes into your computer for a service that xinetd is monitoring, xinetd uses the /etc/xinetd.conf file to read configuration files contained in the /etc/xinetd.d directory. Then based on the contents of the file for this service in the xinet.d directory, a service program is launched to handle the service request (provided that service is not disabled).

References:

Read chapter 12 from the course textbook.
Linux Run level scripts
An introduction to services, runlevels, and rc.d scripts