14.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
init is centrally configured in the /etc/inittab
file where the runlevels are defined (see
Section 14.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 14.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 whose task is to maintain all other processes and
adjust CPU time and hardware access according to requests from other
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 14-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 a the single number 3 to the boot prompt.
Table 14-1 Available Runlevels
S or 1
Single user mode
Local multiuser mode without remote network (NFS, etc.)
Full multiuser mode with network
, this is disabled unless the
administrator configures this runlevel.
Full multiuser mode with network and X display manager—KDM,
GDM, or XDM
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
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
The system halts.
- telinit 6 or shutdown -r
The system halts then reboots.
Runlevel 5 is the default runlevel in all
openSUSE standard installations. Users are prompted for login with
a graphical interface or the default user is logged in automatically. If
the default runlevel is 3, the X Window System must
be configured properly, as described in Section 10.0, The X Window System,
before the runlevel can be switched to 5. If this is
done, check whether the system works in the desired way by entering
telinit 5. If everything turns out
as expected, you can use YaST to set the default runlevel to
WARNING: Errors in /etc/inittab May Result in a Faulty System Boot
If /etc/inittab is damaged, the system might 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
The administrator (root)
requests init to change to a different runlevel by entering
init checks the current runlevel (runlevel) and
determines it should start /etc/init.d/rc with
the new runlevel as a parameter.
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 (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.
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
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.
14.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 clarity
reasons 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 14-2. Scripts that are run directly
by init do not have these links. They are run independently from the
runlevel when needed.
Table 14-2 Possible init Script Options
If the service is running, stop it then restart it. If it is not
running, start it.
Reload the configuration without stopping and restarting the
Reload the configuration if the service supports this. Otherwise,
do the same as if restart had been given.
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 the insserv(8) man page for 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 chkconfig(8) 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
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 block special
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 on the blogd(8) man
The boot script is also responsible for starting
all the scripts in /etc/init.d/boot.d with a
name that starts 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
Here, enter additional commands to execute at boot before changing
into a runlevel. It can be compared to
AUTOEXEC.BAT on DOS systems.
This script is only executed while changing into runlevel 0 or
6. Here, it is executed either as halt or as
reboot. 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
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
WARNING: Faulty init Scripts May Halt Your System
Faulty init scripts may hang your machine. Edit such scripts with great
care and, if possible, subject them to heavy testing in the multiuser
environment. Find some useful information about init scripts in
Section 14.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 14-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 started or stopped before
the service itself is started or 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. The insserv
program 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 14.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
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.
14.2.3 Configuring System Services (Runlevel) with YaST
After starting this YaST module with
, 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
or in . The
default 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 . 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
initdefault (the runlevel into which the system boots by
default) is displayed at the top. Normally, the default runlevel of a
openSUSE system is runlevel 5 (full multiuser mode with
network and X). A suitable alternative might be runlevel 3 (full
multiuser mode with network).
. The current default runlevel or
This YaST dialog allows the selection of one of the runlevels (as
listed in Table 14-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
( , , ,
, , ,
, and ) 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 14-1 System Services (Runlevel)
, decide whether a
service should be activated. checks
the current status. lets you select
whether to apply your changes to the system or to restore the settings
that existed before starting the runlevel editor. Selecting
saves the changed settings to disk.