20.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
Runlevels). The file also specifies which services and
daemons are available in each of the levels. Depending on the entries in
/etc/inittab, several scripts are run by init. For
reasons of clarity, these scripts, called init scripts,
all reside in the directory /etc/init.d (see Section 20.2.2,
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 programs.
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 20-1.
As an alternative, the runlevel can be
specified at boot time (at the boot prompt, for instance). Any parameters
that are not directly evaluated by the kernel itself are passed to
Table 20-1 Available Runlevels
Single user mode; from the boot prompt, only with US
Single user mode
Local multiuser mode without remote network (NFS, etc.)
Full multiuser mode with network
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
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
- 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 SUSE Linux Enterprise
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
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 5.
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
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
Here, in most cases, a number of programs are started. For example, the
following occurs when changing from runlevel 3 to 5:
The administrator (root) requests
init to change to a different runlevel by entering telinit
init consults its configuration file
(/etc/inittab) 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 start, because there are some dependencies to
The last things to start are the start scripts of the new runlevel. These
are, in this example, in
/etc/init.d/rc5.d and begin
with an S. The same procedure regarding the order in
which they are started is applied here.
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.
20.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 ).
For IBM System z systems, this is the
case only during the boot process or if an immediate system shutdown is
initiated (power failure or via
The execution of these scripts is defined in
- 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
force-reload, and status options. These
different options are explained in
Scripts that are run directly by init do not have these links. They
are run independently from the runlevel when needed.
Table 20-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
do the same as if restart had been
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 script.
Executed while starting the system directly using init. It
is independent of the chosen runlevel and is only executed once. Here,
the proc and 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) 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)
The script boot 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. Last executed is the script
Here, enter additional commands to execute at boot before changing into a
runlevel. It can be compared to AUTOEXEC.BAT on DOS
This script is executed when changing from single user mode to any other
runlevel and is responsible for a number of basic settings, such
keyboard layout and initialization of the virtual consoles.
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.
This script calls the appropriate stop scripts of the current runlevel and
the start scripts of the newly selected runlevel.
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,
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. 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
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
The INIT INFO block at the top is a required part of the
script and must be edited. See
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
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.
20.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.
Figure 20-1 System Services (Runlevel)
For detailed control over the runlevels in which a service is started or
stopped or to change the default runlevel, first select
(the runlevel into which the system boots by default) is displayed at the
top. Normally, the default runlevel of a SUSE Linux Enterprise 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
Table 20-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.
, 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.
WARNING: Faulty Runlevel Settings May Damage Your System
Faulty runlevel settings may render a system unusable. Before applying your
changes, make absolutely sure that you know their consequences.