10.2 The init Process

The program init is the process with process ID 1. It is responsible for initializing the system in the required way. init is started directly by the Kernel and resists signal 9, which normally kills processes. All other programs are either started directly by init or by one of its child processes.

init is centrally configured in the /etc/inittab file where the runlevels are defined (see Section 10.2.1, Runlevels). The file also specifies which services and daemons are available in each of the runlevels. Depending on the entries in /etc/inittab, several scripts are run by init. By default, the first script that is started after booting is /etc/init.d/boot. Once the system initialization phase is finished, the system changes the runlevel to its default runlevel with the /etc/init.d/rc script. For reasons of clarity, these scripts, called init scripts, all reside in the directory /etc/init.d (see Section 10.2.2, Init Scripts).

The entire process of starting the system and shutting it down is maintained by init. From this point of view, the Kernel can be considered a background process to maintain all other processes and adjust CPU time and hardware access according to requests from other programs.

10.2.1 Runlevels

In Linux, runlevels define how the system is started and what services are available in the running system. After booting, the system starts as defined in /etc/inittab in the line initdefault. Usually this is 3 or 5. See Table 10-1. As an alternative, the runlevel can be specified at boot time (by adding the runlevel number at the boot prompt, for instance). Any parameters that are not directly evaluated by the Kernel itself are passed to init. To boot into runlevel 3, just add the single number 3 to the boot prompt.

Table 10-1 Available Runlevels

Runlevel

Description

0

System halt

S or 1

Single user mode

2

Local multiuser mode without remote network (NFS, etc.)

3

Full multiuser mode with network

4

User Defined, this is not used unless the administrator configures this runlevel.

5

Full multiuser mode with network and X display manager—KDM, GDM, or XDM

6

System reboot

IMPORTANT: Avoid Runlevel 2 with a Partition Mounted via NFS

You should not use runlevel 2 if your system mounts a partition like /usr via NFS. The system might behave unexpectedly if program files or libraries are missing because the NFS service is not available in runlevel 2 (local multiuser mode without remote network).

To change runlevels while the system is running, enter telinit and the corresponding number as an argument. Only the system administrator is allowed to do this. The following list summarizes the most important commands in the runlevel area.

telinit 1 or shutdown now

The system changes to single user mode. This mode is used for system maintenance and administration tasks.

telinit 3

All essential programs and services (including network) are started and regular users are allowed to log in and work with the system without a graphical environment.

telinit 5

The graphical environment is enabled. Usually a display manager like XDM, GDM or KDM is started. If autologin is enabled, the local user is logged in to the preselected window manager (GNOME or KDE or any other window manager).

telinit 0 or shutdown -h now

The system halts.

telinit 6 or shutdown -r now

The system halts then reboots.

Runlevel 5 is the default runlevel in all SUSE Linux Enterprise Server standard installations. Users are prompted for login with a graphical interface or the default user is logged in automatically.

WARNING: Errors in /etc/inittab May Result in a Faulty System Boot

If /etc/inittab is damaged, the system may not boot properly. Therefore, be extremely careful while editing /etc/inittab. Always let init reread /etc/inittab with the command telinit q before rebooting the machine.

Generally, two things happen when you change runlevels. First, stop scripts of the current runlevel are launched, closing down some programs essential for the current runlevel. Then start scripts of the new runlevel are started. Here, in most cases, a number of programs are started. For example, the following occurs when changing from runlevel 3 to 5:

  1. The administrator (root) requests init to change to a different runlevel by entering telinit 5.

  2. init checks the current runlevel (runlevel) and determines it should start /etc/init.d/rc with the new runlevel as a parameter.

  3. Now rc calls the stop scripts of the current runlevel for which there is no start script in the new runlevel. In this example, these are all the scripts that reside in /etc/init.d/rc3.d (the old runlevel was 3) and start with a K. The number following K specifies the order to run the scripts with the stop parameter, because there are some dependencies to consider.

  4. The last things to start are the start scripts of the new runlevel. In this example, these are in /etc/init.d/rc5.d and begin with an S. Again, the number that follows the S determines the sequence in which the scripts are started.

When changing into the same runlevel as the current runlevel, init only checks /etc/inittab for changes and starts the appropriate steps, for example, for starting a getty on another interface. The same functionality may be achieved with the command telinit q.

10.2.2 Init Scripts

There are two types of scripts in /etc/init.d:

Scripts Executed Directly by init

This is the case only during the boot process or if an immediate system shutdown is initiated (power failure or a user pressing Ctrl+Alt+Del). The execution of these scripts is defined in /etc/inittab.

Scripts Executed Indirectly by init

These are run when changing the runlevel and always call the master script /etc/init.d/rc, which guarantees the correct order of the relevant scripts.

All scripts are located in /etc/init.d. Scripts that are run at boot time are called through symbolic links from /etc/init.d/boot.d. Scripts for changing the runlevel are called through symbolic links from one of the subdirectories (/etc/init.d/rc0.d to /etc/init.d/rc6.d). This is just for reasons of clarity and avoids duplicate scripts if they are used in several runlevels. Because every script can be executed as both a start and a stop script, these scripts must understand the parameters start and stop. The scripts also understand the restart, reload, force-reload, and status options. These different options are explained in Table 10-2. Scripts that are run directly by init do not have these links. They are run independently from the runlevel when needed.

Table 10-2 Possible init Script Options

Option

Description

start

Start service.

stop

Stop service.

restart

If the service is running, stop it then restart it. If it is not running, start it.

reload

Reload the configuration without stopping and restarting the service.

force-reload

Reload the configuration if the service supports this. Otherwise, do the same as if restart had been given.

status

Show the current status of service.

Links in each runlevel-specific subdirectory make it possible to associate scripts with different runlevels. When installing or uninstalling packages, these links are added and removed with the help of the program insserv (or using /usr/lib/lsb/install_initd, which is a script calling this program). See man 8 insserv for more details.

All of these settings may also be changed with the help of the YaST module. If you need to check the status on the command line, use the tool chkconfig, described in the man 8 chkconfig man page.

A short introduction to the boot and stop scripts launched first or last, respectively, follows as well as an explanation of the maintaining script.

boot

Executed while starting the system directly using init. It is independent of the chosen runlevel and is only executed once. Here, the /proc and /dev/pts file systems are mounted and blogd (boot logging daemon) is activated. If the system is booted for the first time after an update or an installation, the initial system configuration is started.

The blogd daemon is a service started by boot and rc before any other one. It is stopped after the actions triggered by these scripts (running a number of subscripts, for example, making special block files available) are completed. blogd writes any screen output to the log file /var/log/boot.msg, but only if and when /var is mounted read-write. Otherwise, blogd buffers all screen data until /var becomes available. Get further information about blogd with man 8 blogd.

The boot script is also responsible for starting all the scripts in /etc/init.d/boot.d with names that start with S. There, the file systems are checked and loop devices are configured if needed. The system time is also set. If an error occurs while automatically checking and repairing the file system, the system administrator can intervene after first entering the root password. The last executed script is boot.local.

boot.local

Here enter additional commands to execute at boot before changing into a runlevel. It can be compared to AUTOEXEC.BAT on DOS systems.

halt

This script is only executed while changing into runlevel 0 or 6. Here, it is executed either as init or as init. Whether the system shuts down or reboots depends on how halt is called. If special commands are needed during the shutdown, add these to the init script.

rc

This script calls the appropriate stop scripts of the current runlevel and the start scripts of the newly selected runlevel. Like the /etc/init.d/boot script, this script is called from /etc/inittab with the desired runlevel as parameter.

You can create your own scripts and easily integrate them into the scheme described above. For instructions about formatting, naming and organizing custom scripts, refer to the specifications of the LSB and to the man pages of init, init.d, chkconfig, and insserv. Additionally consult the man pages of startproc and killproc.

WARNING: Faulty Init Scripts May Halt Your System

Faulty init scripts may hang your machine up. Edit such scripts with great care and, if possible, subject them to heavy testing in the multiuser environment. Find useful information about init scripts in Section 10.2.1, Runlevels.

To create a custom init script for a given program or service, use the file /etc/init.d/skeleton as a template. Save a copy of this file under the new name and edit the relevant program and filenames, paths and other details as needed. You may also need to enhance the script with your own parts, so the correct actions are triggered by the init procedure.

The INIT INFO block at the top is a required part of the script and must be edited. See Example 10-1.

Example 10-1 A Minimal INIT INFO Block

### BEGIN INIT INFO
# Provides:          FOO
# Required-Start:    $syslog $remote_fs
# Required-Stop:     $syslog $remote_fs
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Description:       Start FOO to allow XY and provide YZ
### END INIT INFO

In the first line of the INFO block, after Provides:, specify the name of the program or service controlled by this init script. In the Required-Start: and Required-Stop: lines, specify all services that need to be still running when the service itself is stopped. This information is used later to generate the numbering of script names, as found in the runlevel directories. After Default-Start: and Default-Stop:, specify the runlevels in which the service should automatically be started or stopped. Finally, for Description:, provide a short description of the service in question.

To create the links from the runlevel directories (/etc/init.d/rc?.d/) to the corresponding scripts in /etc/init.d/, enter the command insserv new-script-name. insserv evaluates the INIT INFO header to create the necessary links for start and stop scripts in the runlevel directories (/etc/init.d/rc?.d/). The program also takes care of the correct start and stop order for each runlevel by including the necessary numbers in the names of these links. If you prefer a graphical tool to create such links, use the runlevel editor provided by YaST, as described in Section 10.2.3, Configuring System Services (Runlevel) with YaST.

If a script already present in /etc/init.d/ should be integrated into the existing runlevel scheme, create the links in the runlevel directories right away with insserv or by enabling the corresponding service in the runlevel editor of YaST. Your changes are applied during the next reboot—the new service is started automatically.

Do not set these links manually. If something is wrong in the INFO block, problems will arise when insserv is run later for some other service. The manually added service will be removed with the next run of insserv for this script.

10.2.3 Configuring System Services (Runlevel) with YaST

After starting this YaST module with YaST > System > System Services (Runlevel), it displays an overview listing all the available services and the current status of each service (disabled or enabled). Decide whether to use the module in Simple Mode or in Expert Mode. The default Simple Mode should be sufficient for most purposes. The left column shows the name of the service, the center column indicates its current status and the right column gives a short description. For the selected service, a more detailed description is provided in the lower part of the window. To enable a service, select it in the table then select Enable. The same steps apply to disable a service.

For detailed control over the runlevels in which a service is started or stopped or to change the default runlevel, first select Expert Mode. The current default runlevel or initdefault (the runlevel into which the system boots by default) is displayed at the top. Normally, the default runlevel of a SUSE Linux Enterprise Server system is runlevel 5 (full multiuser mode with network and X). A suitable alternative might be runlevel 3 (full multiuser mode with network).

This YaST dialog allows the selection of one of the runlevels (as listed in Table 10-1) as the new default. Additionally, use the table in this window to enable or disable individual services and daemons. The table lists the services and daemons available, shows whether they are currently enabled on your system and, if so, for which runlevels. After selecting one of the rows with the mouse, click the check boxes representing the runlevels (B, 0, 1, 2, 3, 5, 6, and S) to define the runlevels in which the selected service or daemon should be running. Runlevel 4 is undefined to allow creation of a custom runlevel. A brief description of the currently selected service or daemon is provided below the table overview.

WARNING: Faulty Runlevel Settings May Damage Your System

Faulty runlevel settings may make your system unusable. Before applying your changes, make absolutely sure that you know their consequences.

Figure 10-1 System Services (Runlevel)

With Start, Stop, or Refresh, decide whether a service should be activated. Refresh status checks the current status. Set or Reset lets you select whether to apply your changes to the system or to restore the settings that existed before starting the runlevel editor. Selecting OK saves the changed settings to disk.