Introduction

systemd (stylized lowercase) is a hydra.

In the old world, we had one piece of software for each little thing we wanted to do on a system. Time was handled by NTP, devices were handled by udev, and init was generally handled by SysV Init.

In the new world, we have systemd:

• System clock management can be handled by systemd-timesyncd.
• udev was merged into the systemd code base, forming systemd-udevd.
• Process initialization is handled by the core of systemd itself.

The list goes on.

Generally, systemd has been adopting other projects, or writing the same functionality into implementations of their own (such as systemd-timesyncd which is an NTP replacement.) However, the systemd suite is also modular, meaning that distributions can broadly choose which bits to adopt and use.

For us, the important job that systemd does is replace the traditional init system on distributions (CentOS, Debian, and Ubuntu all use systemd now). This means that first and foremost, systemd manages services and daemons on your box.

In this chapter, we're going to work with the init component of systemd, learn about unit files, and determining the running state of our system.

Previously, this chapter could have been much longer. Prior to systemd dominating each and every mainstream distribution, fragmentation existed. Canonical wrote something called Upstart for Ubuntu (which was temporarily adopted by Red Hat), and more traditional distributions had a hard time letting go of the SysV init style of daemon management. Even today, you'll find systems that use older implementations in the wild:

• CentOS adopted systemd with version 7
• Ubuntu adopted systemd with 15.04
• Debian adopted systemd with Jessie (8)