The advantages of systemd

We've just seen the problems with SysV and upstart. Now, let's look at what makes systemd better.

systemd's simplicity

In contrast to SysV, systemd is really quite simple to configure. For example, look at how short the Apache service file is on a CentOS 7 machine with systemd:

[donnie@localhost ~]$ cd /lib/systemd/system
[donnie@localhost system]$ ls -l httpd.service
-rw-r--r--. 1 root root 752 Jun 26  2018 httpd.service
[donnie@localhost system]$ wc -l httpd.service
22 httpd.service
[donnie@localhost system]$

There are only 22 lines, and 5 of those lines are comments, as you can see here:

Figure 1.3 – A systemd service file

I'll explain everything in the systemd files later. For now, I just want to show you that a systemd service file is much simpler than a SysV init script. (As we'll soon see in the upcoming chapters, it's easier to learn how to use the systemd directives than it is to learn how to write shell-scripting code for init scripts.)

systemd's consistency

The next systemd advantage is its consistency. Yes, boys and girls, you no longer have to remember multiple sets of system management commands for multiple families of Linux distros. Instead, you'll now use the same commands on all Linux distros that use systemd. So, this eliminates a major source of frustration for administrators, and for anyone who's studying to take a Linux certification exam.

systemd's performance

In contrast to SysV, systemd can start services in parallel, rather than just one at a time in sequence. This makes for much quicker boot-up times than for SysV. Once the machine is booted, performance is more robust than that of SysV.

With systemd, we have a much cleaner way of killing processes. For example, if you needed to use the kill command to forcefully terminate the Apache web server service on a SysV machine, you would only terminate the Apache process itself. If the web server process had spawned any child processes due to running CGI scripts, for example, those processes would continue on for a while longer as zombie processes. But, when you kill a service with systemd, all processes that are associated with that service will also get terminated.

systemd security

An added bonus is that you can configure systemd service files to control certain aspects of system security. Here are some of the things that you can do:

• You can create a systemd service that can restrict access to or from certain directories, or that can only access or be accessed from certain network addresses.
• By using namespaces, you can effectively isolate services from the rest of the system. This also allows you to create containers without having to run Docker.
• You can use cgroups to limit resource usage. This can help prevent certain types of denial-of-service attacks.
• You can specify which root-level kernel capabilities a service is allowed to have.

With all this, you can make systemd somewhat emulate a mandatory access control system, such as SELinux or AppArmor.

All the way around, systemd is much better than any init system that came before it. But it hasn't made everyone happy.