So you’ve been starting and stopping your daemons with /etc/init.d scripts. Stubbornly you hold on to reaching for those gems in /etc/init.d/ over and over. But you know about the service program. How sweet it is to just type service apache2 status and see the output rushing past in the terminal.
A reinvented wheel? Well..
But then something happened. There was a new Linux boot time player in town and its name was systemctl and plenty of Linux users did not use it at once. “Seriously”, some thought to themselves – Another utility to start and stop daemons?! Well yes, but also no. For us that were used to calling init.d scripts directly or use the service utility, it seemed like here was another solution to do exactly the same thing. Woe. Haven’t we seen this so many times in the world of Linux. But it turns out that systemctl does more than that. It’s part of the systemd initiative which was an init replacement daemon. Systemd which controls and manages user services is meant to replace the init daemon.
Systemctl deals with the Kernel Panic
The goal was to start processes in parallel. This was to avoid the much too familiar Kernel Panic error that occurs when the init daemon could not start for some reason.
Systemd, or the System Management Daemon, is also the parent of all other processes. The key difference here is that it uses parallel processing during boot. It doesn’t stop there though. Systemd added plenty of new features as compared with Upstart on Ubuntu. Systemd will only start processes if they are depended on by another programs at startup. Compare that with Upstart which would power up all startup events as fast as possible.
The transition solution came in Ubuntu 15.04, it was possible to switch between upstart and systemd. Both packages were installed. From then on Systemd was accepted by several major distributions. We now see CentOS (and RedHat), Debian, Slack, and Ubuntu using systemd as well. That is a pretty major shift in the way of handling system startup across Linux distributions.
Changes that stretches further than start/stop/status
The changes that came with Systemd stretches far. For instance, Systemd is not POSIX compliant but does use the Unix Domain Socket. Fedora was the first distribution to feature Systemd but many others followed suit.
Some say nay to Systemd
Yet there are critics to systemd.. Some say that systemd is way too complex and “violates the design principle of Unix-like operating systems” (see Systemd criticism section on Wikipedia for full context). So when you fire up that Apache2 daemon next time, remember that you can do more than that. There’s the possibility to see dependencies, the possibility to queue jobs according to already queued jobs, and more. You can tailor a Linux startup in great detail with Systemd. Read more about Systemd at the Fedora project.