Process Initialization
A Linux system includes lots of programs running in background to provide services for the system. It’s the init program’s job to start all of those programs when the Linux system starts up. This is called the initialization process.
You must configure the initialization process to start programs based on the desired features you want running in your Linux system. For example, a Linux server doesn’t necessarily need to start a graphical desktop environment, or a Linux desktop doesn’t necessarily need to start the Apache web server service.
While several initialization methods are available in Linux, two have risen to the top and are the most popular used in Linux distributions:
Unix System V (also called SysVinit)
Systemd
The original Linux init program was based off of the Unix System V init program, and became commonly called SysVinit. The init program uses a series of shell scripts, divided into separate runlevels, to determine what programs run at what times. Each program uses a separate shell script to start and stop the program. The system administrator sets which runlevel the Linux system starts in, which in turn determines which set of programs are running. The system administrator can also change the runlevel at any time while the system is running.
The init program had served the Linux community well for many years, but as Linux systems became more complicated and required more services, the runlevel shell scripts have become more complicated. This has caused Linux developers to look for other solutions.
The systemd program was developed by the Red Hat Linux distribution to handle dynamic Linux environments. Instead of runlevels it uses targets and units to control what applications run at any time on the system. It uses separate configuration files that determine this behavior.
To find out which method your Linux system uses, use the ps command to display the program assigned process ID (PID) 1:
The output from this Ubuntu system shows that it’s running the systemd program. The following sections take a closer look at each of these initialization process methods to help you get comfortable in any Linux environment.
The SysVinit Method
The key to the SysVinit initialization process is runlevels. The init program determines which programs to start, based on the runlevel of the system.
Runlevels are numbered from 0 to 6, and each one is assigned a set of programs that should be running for that runlevel. When the Linux kernel starts, it determines which runlevel to start by a configuration file. It’s important to know how to manage runlevels and how to determine when each runlevel is used by the kernel. The following sections show how to do just that.
Runlevels
While each Linux distribution defines applications that should be running at specific runlevels, you can use some general guidelines. TABLE 4-2 shows the general use of the Linux runlevels.
TABLE 4-2 Linux runlevels.
| Runlevel | Description |
|---|---|
| 0 | Shut down the system |
| 1 | Single-user mode. Used for system maintenance. |
| 2 | On Debian-based systems, multi-user graphical mode |
| 3 | On Red Hat-based systems, multi-user text mode |
| 4 | Undefined |
| 5 | On Red Hat–based systems, multi-user graphical mode |
| 6 | Reboot the system |
Most Linux distributions use the Red-Hat runlevel method of using runlevel 3 for multi-user text mode and runlevel 5 for multi-user graphical mode.
Starting applications in a runlevel
There are two ways to start applications in runlevels:
Using the /etc/inittab file
Using startup scripts
The /etc/inittab file defines what applications start at which runlevel. Each line in the /etc/inittab file defines an application and uses the following format:
The id field contains one to four characters that uniquely defines the process. The runlevels field contains a list of runlevels in which the application should be running. The list is not comma separated, so the value 345 indicates the application should be started in runlevels 3, 4, and 5.
The action field contains a keyword that tells the kernel what to do with the application for that runlevel Possible values are shown in TABLE 4-3.
TABLE 4-3 The SysV inittab action values.
| Action | Description |
|---|---|
| boot | The process is started at boot time. |
| bootwait | The process is started at boot time and the system will wait for it to finish. |
| initdefault | The runlevel to enter after the system boots is specified. |
| kbrequest | The process is started after a special key combination is pressed. |
| once | The process is started once when the runlevel is entered. |
| powerfail | The process is started when the system is powered down. |
| powerwait | The process is started when the system is powered down, and the system will wait for it to finish. |
| respawn | The process is started when the runlevel is entered and restarted whenever it terminates. |
| sysinit | The process is started at boot time before any boot or bootwait items. |
| wait | The process is started once and the system will wait for it to finish. |
The initdefault line specifies the runlevel that the system normally runs in after boot:
Besides the runlevels, the SysVinit method also specifies startup scripts to control how applications start and stop. The /etc/init.d/rc or /etc/rc.d/rc script runs all scripts with a specified runlevel. The scripts themselves are stored in the /etc/init.d/rcx.d or /etc/rcx.d folders, where x is the runlevel number.
Scripts are stored with a specific filename that specifies whether they start or stop at the runlevel. Scripts that start with an S start the program, and scripts that start with a K stop it. The script filenames also contain a number, which indicates the order the rc program runs the scripts. This allows you to specify which scripts get started before others to control any dependency issues.
Checking the runlevel
You’ve seen that the /etc/inittab file indicates the default runlevel with the initdefault action; however, there’s no guarantee that’s the runlevel your Linux system is currently running at. The runlevel command displays both the current runlevel and the previous runlevel for the system:
The first character is the previous runlevel. The N character means the system is in the original boot runlevel. The second character is the current runlevel.
Changing Runlevels
You can change the current runlevel of your Linux system using either the init or telinit command. Just specify the runlevel number as the command line parameter. For example, to reboot your system you can enter the command:
The downside to using the init command is that it immediately changes the system to the specified runlevel. That may not be an issue if you’re the only person on your Linux system, but in a multi-user Linux environment that can have adverse effects for the other users.
A kinder way to change the runlevel on multi-user systems is to use one of a handful of special commands used just for that purpose:
shutdown—Gracefully changes the runlevel to 1, or single-user mode
halt—Gracefully changes the runlevel to 0 to stop the system
poweroff—Gracefully changes the runlevel to 0 to stop the system
reboot—Gracefully changes the runlevel to 6 to restart the system
Each of these commands also allow you to specify a message to send to any other users on the system before it changes the runlevel. You can also specify a time for the change, such as +15 for 15 minutes, along with a message to send to other users.
The Systemd Method
The systemd initialization process method has quickly become a standard. While it started out as a Red Hat feature, now most Linux distributions have adopted it as their default initialization method.
The systemd initialization process introduced a major paradigm shift in how Linux systems handle services, which has also caused some controversy in the Linux world. Instead of lots of small initialization shell scripts, the systemd method uses one monolithic program that uses individual configuration files for each service. This is somewhat of a departure from earlier Linux philosophy.
This section walks through the basics of how the systemd initialization process works.
Units and targets
Instead of using shell scripts and runlevels, the systemd method uses units and targets. A unit defines a service or action on the system. It consists of a name, a type, and a configuration file. There are currently 12 different types of systemd units:
automount
device
mount
path
scope
service
slice
snapshot
socket
swap
target
timer
The systemd program identifies units by their name and type using the format name.type. You use the systemctl command when working with units. To list the units currently loaded in your Linux system, use the list-units parameter:
Linux distributions can have hundreds of different units loaded and active, this listing shows just a few from the output to show you what they look like. The systemd method uses service type units to manage the daemons on the Linux system. The target type units are important in that they group multiple units together so they can be started at the same time. For example, the network.target unit groups all the units required to start the network interfaces for the system.
The systemd initialization process uses targets similar to the way SysV runlevels. Each target represents a different group of services that should be running on the system. Instead of changing runlevels to alter what’s running on the system, you just change targets.
To make the transition from SysV to systemd smoother, there are targets that mimic the standard 0 through 6 SysV runlevels, called runlevel0.target through runlevel6.target.
Configuring units
Each unit requires a configuration file that defines what program it starts and how it should start the program. The systemd system stores unit configuration files in the /usr/lib/systemd/system folder. Here’s an example of the cron.service unit configuration file used in Ubuntu:
The cron.service configuration file defines the program to start (/usr/sbin/cron), along with some other features, such as what services should run before the cron service starts (the After line), what target level the system should be in (the WantedBy line), and how to reload the program (the Restart line).
Target units also use configuration files. They don’t define programs but, instead, define which service units to start. Here’s an example of the graphical.target unit configuration file used in CentOS:
The target configuration defines what targets should be loaded first (the After line), what targets are required for this target to start (the Requires line), what targets conflict with this target (the Conflicts line), and what targets or services the target requires to be running (the Wants line).
Setting the default target
The default target used when the Linux system boots is defined as the file default.target, located in the /usr/lib/systemd/system folder. This is the file the systemd program looks for when it starts up. This file is normally set as a link to a standard target file also in the /usr/lib/systemd/system folder:
On this Ubuntu system, the default target is set to the graphical.target unit.
You can also see the default target for the system by using the systemctl command:
This again shows that the graphical.target target is the default.
The systemctl program
You use the systemctl program to also control services and targets. The systemctl program uses options to define what action to take, as shown in TABLE 4-4.
TABLE 4-4 The systemctl commands.
| Command name | Explanation |
|---|---|
| get-default | Displays the default target configured for the system |
| list-units | Displays the current status of all configured units |
| default name | Changes to the default target unit |
| isolate name | Starts the named unit and stops all others |
| start name | Starts the named unit |
| stop name | Stops the named unit |
| reload name | Causes the named unit to reload its configuration file |
| restart name | Causes the named unit to shut down and restart |
| status name | Displays the status of the named unit (You can pass a PID value rather than a name, if you like.) |
| enable name | Configures the unit to start when the computer next boots |
| disable name | Configures the unit to not start when the computer next boots |
Instead of using shell scripts to start and stop services, you use the start and stop commands:
To change the target that is currently running, you must use the isolate command. For example, to enter single-user mode you’d use:
To go back to the default target for the system, you just use the default command.
One of the more controversial features of the systemd initialization process is that it doesn’t use the standard Linux syslogd log file system. Instead, it has its own log files, and those log files are not stored in text format. To view the systemd log files, you need to use the journalctl program.