The kernel, once it is loaded, finds init
in sbin and executes it.
When init starts, it becomes the parent
or grandparent of all of the processes that start up automatically
on your Linux system. The first thing init
does, is reading its initialization file, /etc/inittab. This instructs init to read an initial configuration script for the
environment, which sets the path, starts swapping, checks the file
systems, and so on. Basically, this step takes care of everything
that your system needs to have done at system initialization:
setting the clock, initializing serial ports and so forth.
Then init continues to read the
/etc/inittab file, which describes how
the system should be set up in each run level and sets the default
run level. A run level is a configuration of processes.
All UNIX-like systems can be run in different process
configurations, such as the single user mode, which is referred to
as run level 1 or run level S (or s). In this mode, only the system
administrator can connect to the system. It is used to perform
maintenance tasks without risks of damaging the system or user
data. Naturally, in this configuration we don't need to offer user
services, so they will all be disabled. Another run level is the
reboot run level, or run level 6, which shuts down all running
services according to the appropriate procedures and then restarts
Use the who to check what your current
run level is:
More about run levels in the next section, see
After having determined the default run level for your system,
init starts all of the background processes
necessary for the system to run by looking in the appropriate
rc directory for that run level.
init runs each of the kill scripts (their
file names start with a K) with a stop parameter. It then runs all
of the start scripts (their file names start with an S) in the
appropriate run level directory so that all services and
applications are started correctly. In fact, you can execute these
same scripts manually after the system is finished booting with a
command like /etc/init.d/httpd stop or service
httpd stop logged in as root, in
this case stopping the web server.
Note that on system startup, the scripts in rc2.d and rc3.d are
usually executed. In that case, no services are stopped (at least
not permanently). There are only services that are started.
None of the scripts that actually start and stop the services
are located in /etc/rc<x>.d.
Rather, all of the files in /etc/rc<x>.d are symbolic links that point to
the actual scripts located in /etc/init.d. A symbolic link is nothing more than a
file that points to another file, and is used in this case because
it can be created and deleted without affecting the actual scripts
that kill or start the services. The symbolic links to the various
scripts are numbered in a particular order so that they start in
that order. You can change the order in which the services start up
or are killed by changing the name of the symbolic link that refers
to the script that actually controls the service. You can use the
same number multiple times if you want a particular service started
or stopped right before or after another service, as in the example
below, listing the content of /etc/rc5.d,
where crond and xfs
are both started from a linkname starting with "S90". In this case, the scripts are started in
After init has progressed through the run
levels to get to the default run level, the /etc/inittab script forks a getty process for each virtual console (login prompt
in text mode). getty opens tty lines, sets
their modes, prints the login prompt, gets the user's name, and
then initiates a login process for that user. This allows users to
authenticate themselves to the system and use it. By default, most
systems offer 6 virtual consoles, but as you can see from the
inittab file, this is configurable.
/etc/inittab can also tell init how it should handle a user pressing Ctrl+Alt+Delete at the console. As the system should be
properly shut down and restarted rather than immediately
power-cycled, init is told to execute the
command /sbin/shutdown -t3
-r now, for instance,
when a user hits those keys. In addition, /etc/inittab states what init should do in case of power failures, if your
system has a UPS unit attached to it.
On most RPM-based systems the graphical login screen is started
in run level 5, where /etc/inittab runs a
script called /etc/X11/prefdm. The
prefdm script runs the preferred X
display manager, based on the contents of the /etc/sysconfig/desktop directory. This is typically
gdm if you run GNOME or kdm if you run KDE, but they can be mixed, and
there's also the xdm that comes with a
standard X installation.
But there are other possibilities as well. On Debian, for
instance, there is an initscript for each of the display managers,
and the content of the /etc/X11/default-display-manager is used to
determine which one to start. More about the graphical interface
can be read in
Ultimately, your system documentation will explain the details
about the higher level aspects of init.
The /etc/default and/or /etc/sysconfig directories contain entries for a
range of functions and services, these are all read at boot time.
The location of the directory containing system defaults might be
somewhat different depending on your Linux distribution.
Besides the graphical user environment, a lot of other services
may be started as well. But if all goes well, you should be looking
at a login prompt or login screen when the boot process has
We explained how SysV init works on x86
based machines. Startup procedures may vary on other architectures
and distributions. Other systems may use the BSD-style init, where startup files are not split up into
directories. It might also be possible that your system uses
/etc/rc.d/init.d instead of /etc/init.d.