Book Excerpt: A Practical Guide to Fedora and Red Hat Enterprise Linux

The init Daemon

The init daemon is the system and service manager for Linux. It is the first true process Linux starts when it boots and as such, has a PID of 1 and is the ancestor of all processes. The init daemon has been around since the early days of UNIX, and many people have worked to improve it. The first Linux init daemon was based on the UNIX System V init daemon and is referred to as SysVinit (System V init daemon).

Because SysVinit does not deal
well with modern hardware, including
hotplug devices,
USB hard and flash drives, and
network-mounted filesystems,
Fedora/RHEL recently replaced
it with the Upstart init daemon
(http://upstart.ubuntu.com/ and
http://upstart.ubuntu.com/wiki).
Fedora 15 has
moved past Upstart to systemd init daemon,
which is described next. Several
other replacements for SysVinit
are also available. One of the
most prominent is initng (http://initng.sourceforge.net/trac).
In addition, Solaris uses SMF (Service
Management Facility), and MacOS
uses launchd.

The systemd init Daemon (Fedora)

The name systemd comprises system, which systemd manages, followed by d. Under UNIX/Linux, daemon names frequently end in d: systemd is the system daemon. At boot time, systemd renames itself init, so you will not see a process named systemd. However, init is simply a link to systemd:

The name is also a play on words
with System D, a reference
to the French dérouillard
(to untangle) or démerder.
System D is a manner of responding
to challenges that requires fast
thinking, adapting, and improvising.

Service Units and Target Units

The systemd init daemon is based on the concept of units, each of which has a name and type. Typically information about a unit is stored in a file that has the same name as the unit (e.g., dbus.service). The types of units are service, socket, device, mount, automount, target, snapshot, timer, swap, and path. This section discusses service and target units, which are critical to controlling daemons and runlevel under systemd.

Service unit

A service unit refers to a daemon (service) that systemd controls, including those controlled natively by systemd and those controlled by systemd via SysVinit scripts. For example, systemd controls the ntpd daemon natively via the ntpd.service service unit.

Target unit

A target unit groups other units.
Of concern in this section are
targets that control the system
runlevel. By default, Fedora
activates graphical.target,
which brings the system to a
runlevel that equates to what
was formerly called runlevel
5 (multiuser graphical mode).
Activating multi-user.target brings
the system to what was formerly
called runlevel 3 (multiuser
textual mode).

Terminology: server, service, daemon

A daemon, such as ntpd or cupsd, provides a service that runs on a server. The daemon itself is also sometimes referred to as a server. These three terms can be used interchangeably.

Runlevels

The systemd init daemon does not support runlevels the way SysVinit did. It supports target units, which parallel runlevels but are different. To ease the transition, this book continues to use the term runlevel to refer to target units. One difference between SysVinit runlevels and systemd target units is that the former can be changed only when the system changes runlevels while the latter can be activated by any of a large group of triggers. Another difference is that a systemd-based system can activate more than one target unit at a time, allowing the system to be in more than one runlevel at a time. For example, graphical.target pulls in multi-user.target so they are both active at the same time.

systemd runlevels differ from SysVinit runlevels - For consistency and clarity during the transition from SysVinit to systemd, this book refers to systemd target units as runlevels. Target units are not true runlevels, but they perform a function similar to the function performed by SysVinit runlevels.

Wants and Requires

Under systemd, the terms wants and requires specify units that are to be activated when the unit that wants or requires the other unit is activated. A unit that requires another unit will not start if the other unit is not available and will quit if the other unit becomes unavailable while the first unit is active. Wants is similar to requires, except a unit that wants another unit will not fail if the wanted unit is not available.