6.1 Introduction to init

init is a user-space program like any other program on the Linux system, and you’ll find it in /sbin along with many of the other system binaries. Its main purpose is to start and stop the essential service processes on the system.

On all current releases of major Linux distributions, the standard implementation of init is systemd. This chapter focuses on how systemd works and how to interact with it.

There are two other varieties of init that you may encounter on older systems. System V init is a traditional sequenced init (Sys V, usually pronounced “sys-five,” with origins in Unix System V), found on Red Hat Enterprise Linux (RHEL) prior to version 7.0 and Debian 8. Upstart is the init on Ubuntu distributions prior to version 15.04.

Other versions of init exist, especially on embedded platforms. For example, Android has its own init, and a version called runit is popular on lightweight systems. The BSDs also have their own version of init, but you’re unlikely to see them on a contemporary Linux machine. (Some distributions have also modified the System V init configuration to resemble the BSD style.)

Different implementations of init have been developed to address several shortcomings in System V init. To understand the problems, consider the inner workings of a traditional init. It’s basically a series of scripts that init runs, in sequence, one at a time. Each script usually starts one service or configures an individual piece of the system. In most cases, it’s relatively easy to resolve dependencies, plus there’s a lot of flexibility to accommodate unusual startup requirements by modifying scripts.

However, this scheme suffers from some significant limitations. These can be grouped into “performance problems” and “system management hassles.” The most important of these are as follows:

• Performance suffers because two parts of the boot sequence cannot normally run at once.
• Managing a running system can be difficult. Startup scripts are expected to start service daemons. To find the PID of a service daemon, you need to use ps, some other mechanism specific to the service, or a semistandardized system of recording the PID, such as /var/run/myservice.pid. p. 139
• Startup scripts tend to include a lot of standard “boilerplate” code, sometimes making it difficult to read and understand what they do.
• There is little notion of on-demand services and configuration. Most services start at boot time; system configuration is largely set at that time as well. At one time, the traditional inetd daemon was able to handle on-demand network services, but it has largely fallen out of use.

Contemporary init systems have dealt with these problems by changing how services start, how they are supervised, and how the dependencies are configured. You’ll soon see how this works in systemd, but first, you should make sure that you’re running it.