In this first chapter, we'll first briefly look at the history of Linux
init systems. We'll then look at the shortcomings of the legacy
init systems and why certain Linux engineers felt the need to develop a new type of
init system. Finally, we'll look at the controversy that has surrounded
systemd. For easy reference, here's a list of the topics:
- The history of Linux
- The shortcomings of SysV
- The advantages of
So, with the introductory comments out of the way, let's jump in.
The history of Linux init systems
So, what is an
init system? Well,
init is short for initialization. An
init system, then, initializes the operating system upon bootup. After the bootup has completed, the
init system will continue working, managing system processes and services. Each system process is assigned a process ID number, or PID. The
init process is always PID 1, and every other process that gets started on the system is either a child or a grandchild of the
For many years, the SysV Init system was the primary
init system for Linux-based operating systems (SysV is short for System 5. The V is the Roman numeral for 5). SysV
init was originally developed by Bell Labs engineers for the Unix operating system, all the way back in the early 1970s. (At that time, I was a young pup in junior high school, and I still had a full head of hair.)
There are actually a few more Linux
init systems besides the ones that I'm mentioning here. But these were the most commonly used ones in the pre-
init worked well in its day, but it was never perfect. Nowadays, with new high-performance hardware, SysV
init has shown both its age and its deficiencies. The first attempt to come up with something better occurred in July 2009, when Ubuntu engineers released the first version of the upstart
init system. Although it was better than SysV, it still had its share of problems, especially the early versions which were quite buggy.
The shortcomings of SysV Init and upstart
The first problem with SysV is that of its rather lengthy boot-up times. When you boot up a SysV machine, all of its services have to start up in sequential order. That might not be so bad on a normal desktop machine, but it can be a bit problematic on a server that needs to run lots of services. In that case, each service would have to wait its turn to start, which could take a while.
The next problem with SysV is its complexity. Instead of simple, easy-to-understand configuration files, SysV does everything with complex Bash shell scripts. The
init scripts that control system services all have to be assigned a priority number, so that services will start and stop in the proper order. Take, for example, the
init script that starts the Apache web server on a CentOS 5 machine. First, we can see that it's a fairly lengthy script, as shown here:
[student@localhost init.d]$ pwd /etc/init.d [student@localhost init.d]$ ls -l httpd -rwxr-xr-x 1 root root 3523 Sep 16 2014 httpd [student@localhost init.d]$ wc -l httpd 131 httpd [student@localhost init.d]$
[student@localhost init.d]$ grep ^# httpd | wc -l 37 [student@localhost init.d]$
Look inside, and you'll see that it's quite complex and convoluted. Here's just the first part of it:
Toward the end of the script, you'll see the code that stops, starts, restarts, and reloads the Apache daemon, as shown here:
This code, or code similar to this, has to be in every
init script so that the human user can control the daemon. To complicate things even more, developers didn't always write this code consistently for different programs. So, for example, a status display for one daemon didn't always look the same as the status display for another daemon.
Then, there's the problem of inconsistent implementation across the different families of Linux distros. With SysV, there were at least three different methods of implementation. Red Hat-type distros used one method, Debian-type distros used another method, and Slackware-type distros use yet another. For example, the Red Hat way of controlling services required using the
chkconfig commands. When working with Debian-type systems, I always used to have to look up the service management commands, because I could never remember them. With Slackware, you don't have any service management commands. To enable or disable a service on a Slackware machine, you just set or remove the executable permission from the appropriate
Runlevels were also a source of confusion, because each family of distro had its own set of runlevel definitions. For example, here are the definitions for the graphical runlevel:
- The Red Hat family used runlevel 5.
- The Slackware family uses runlevel 4.
- The Debian family used no specific runlevel for either text mode or graphical mode. Instead, you enabled or disabled graphical mode by enabling or disabling the X server daemon.
As if this weren't enough, there was also the issue of performance. SysV worked well in its day, when computing hardware was more primitive. But, on modern hardware with multiple CPUs that each have multiple cores, we need something a bit more robust. Ubuntu's upstart was supposed to fix this, but it didn't quite live up to its promise. Nowadays, Upstart is completely dead, but there are still some diehards who refuse to give up SysV. In the enterprise,
systemd is king.
The advantages of 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]$
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
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.
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.
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.
- You can create a
systemdservice 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
cgroupsto 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.
The systemd controversy
If you've been in the computer world for any length of time, you may have seen that we geeks can get quite passionate about our operating systems. In the early 1990s, I finally replaced my text mode-only 8088 machine with one that could run a graphical interface. I first gave Windows 3.1 a try, and quickly decided that I really hated it. So, I bought a copy of OS/2, which I liked much better and ran for quite a few years on my home-built 486 machine. But, all of my geek buddies at work were big Windows fans, and they kept arguing with me about how much better Windows is. I thought that they were all crazy, and we kept getting into some rather heated arguments.
Then, when I got into Linux, I quickly learned that you don't want to go into any Linux forum and ask which Linux distro is the best for a newbie to start with. All that does is start fights, leaving the poor newbie more confused than ever. And now, the fight is over whether or not
systemd is a good thing. Here are some of the objections:
- By trying to do too much,
systemdviolates the Unix concept of having each utility just do one thing but having it do it well.
- It's controlled by a large corporation (Red Hat).
- It's a security problem.
journaldcomponent saves system logs to a binary format, which some people believe is more easily corrupted than the plain-text files that
If you look at things objectively, you might see that the objections aren't so bad:
- Yes, the
systemdecosystem includes more than just the
initsystem. It also includes network, bootloader, logging, and log-in components. But those components are all optional, and not all Linux distros use them in a default setup.
- It was created primarily by Red Hat, and the project leader is a Red Hat employee. But Red Hat released it under a free-as-in-speech software license, which means that no one company can ever take full control of it. Even if Red Hat were to suddenly decide that future versions of
systemdwere to be proprietary, the free code is still out there, and someone would fork it into a new free version.
- Yes, there have been some security bugs in
systemd. But that's also true of OpenSSL, the Bash shell, and even the Linux kernel itself. To complain about
systemd'ssecurity would only be valid if the bugs hadn't gotten fixed.
journaldcomponent does create log files in a binary format. But it's still possible to run
systemddistros, and most do. Some distros, such as the Red Hat Enterprise Linux 8 family, use
journaldto gather system information and then just have
journaldpass the information to
rsyslogin order to create normal text files. So, with RHEL 8, we have the best of both worlds.
Soon after the release of
systemd, some people who had never even tried it put up blog posts that explained why
systemd was pure evil and that they would never use it. A few years ago, I created a
systemd tutorial playlist on my BeginLinux Guru channel on YouTube. The first video is called Why systemd?. Quite a few people left comments about why they would never use
systemd and said that they would change to either a non-
systemd Linux distro or to a FreeBSD-type distro in order to avoid it.
The bottom line is this: all enterprise-grade Linux distros now use
systemd. So, I think that it might be here to stay.
In this first chapter, we've looked at the history of the most common Linux init systems. We've seen the ways in which the legacy init systems are deficient, and we've seen why
systemd is a much better replacement. We wrapped things up by looking at the objections against
One of the challenges of learning
systemd is that, until now, there hasn't been any real comprehensive documentation about it. There's basic usage documentation on the Red Hat website, but it doesn't even cover all components of the
systemd ecosystem. There are only two
systemd-specific books that I could find, which are a few years old. (One book is specific to Fedora, the other is specific to Ubuntu.) Even those books leave some things out. So, the challenge I've set for myself is to create a comprehensive, hands-on guide for all things
systemd. In the chapters that follow, I'll do my best to accomplish that goal.
In the next chapter, we'll go on a quick tour of the
systemd directories and files. I'll see you there.
- Who created the original SysV
a. Bell Labs
b. Red Hat
- Which of the following is true about SysV?
a. It's a modern, robust
b. When booting a machine, it can start services in parallel.
c. When booting a machine, it can only start services sequentially.
d. It has security features that
- Which of the following is not true about
a. It has security features that can somewhat emulate a mandatory access control system.
b. It can start services in parallel.
c. It can use
cgroupsto limit resource usage.
d. It's a legacy system that needs to be replaced.
- An overview of Linux
initneeded to be replaced with
- Red Hat's
- Some arguments against