Chapter 9. Starting up - the init Program

I looked at how the kernel boots up to the point that it launches the first program, init, in Chapter 4, Porting and Configuring the Kernel and in Chapter 5, Building a Root Filesystem and Chapter 6, Selecting a Build System, I looked at creating root filesystems of varying complexity, all of which contained an init program. Now it is time to look at the init program in more detail and discover why it is so important to the rest of the system.

There are many possible implementations of init. I will describe the three main ones in this chapter: BusyBox init, System V init, and systemd. For each one, I will give an overview of how it works and the types of system it suits best. Part of that is balancing the trade-off between complexity and flexibility.

After the kernel has booted

We saw in Chapter 4, Porting and Configuring the Kernel, how the kernel bootstrap code seeks to find a root filesystem, either initramfs or a filesystem specified by root= on the kernel command line, and then to execute a program which, by default, is /init for initramfs, and /sbin/init for a regular filesystem. The init program has root privilege and since it is the first process to run, it has a process ID (PID) of 1. If, for some reason, init cannot be started, the kernel will panic.

The init program is the ancestor of all other processes, as shown here by the pstree command, which is part of the psmisc package in most distrubutions:

# pstree -gn

init(1)-+-syslogd(63)
        |-klogd(66)
        |-dropbear(99)
        `-sh(100)---pstree(109)

The job of the init program is to take control of the system and set it running. It may be as simple as a shell command running a shell script – there is an example at the start of Chapter 5, Building a Root Filesystem—but, in the majority of cases, you will be using a dedicated init daemon. The tasks it has to perform are as follows:

• At boot, it starts daemon programs, configures system parameters and the other things needed to get the system into a working state.
• Optionally, it launches daemons, such as getty on terminals which allow a login shell.
• It adopts processes that become orphaned as a result of their immediate parent terminating and there being no other processes in the thread group.
• It responds to any of init's immediate children terminating by catching the signal SIGCHLD and collecting the return value to prevent them becoming zombie processes. I will talk more about zombies in Chapter 10, Learning About Processes and Threads.
• Optionally, it restarts those daemons that have terminated.
• It handles system shutdown.

In other words, init manages the lifecycle of the system, from boot up to shutdown. The current thinking is that init is well placed to handle other runtime events such as new hardware and the loading and unloading of modules. This is what systemd does.