Systemd – What You Need to Know

Unless you have been living under a rock, or worse – you don’t care much about how Linux works, you must have heard of systemd, the (relatively) new init system replacing the old and outdated SysV init recently adopted by most major Linux distros.

What is an init system?

When your Linux machine starts up it will first run some “built-in” code, loaded from the BIOS or UEFI first, followed by the bootloader, which according to its configuration loads a Linux kernel. The kernel loads up drivers, and as its very first job starts up the init process, which being the first gets PID (Process ID) 1 assigned to it.

From the user’s point of view this looks like starting up networking and databases, etc., but in reality there is a rather complex process taking place under the hood. Services are started, stopped and restarted, often parallel to each other. Some are run under different privileges than others, service statuses are being reported and logged, and many other tasks are performed that will make the different part of your system work and be able to interact with its users and environment.

How this is implemented, however, is far from uniform, and this really is where it all stops being common and well-defined.

The old init system

The init system used by most mainstream Linux distros up to recently was System V init (or SysV init in short), which has derived its name form UNIX System V (Pronounced “System Five”), the first commercially available UNIX system. System V OS has had a specific way to run its init process, and SysV init has kept loyal to this over the years.

And it has been many years. UNIX System V was originally released in 1983, making the init SysV init an over 30 years old approach towards starting up Linux machines.

The need for a change

As it has been noted, SysV init has been outdated and long overdue to be replaced. Some of the reasons for this include:

• SysV init uses /sbin/init to start the init process, but init itself has a very limited role. init does little more than starting /etc/init.d/rc, according to the configuration read from /etc/inittab, which in turn will run scripts to do the real work of the init process. This, unless panelized explicitly (like with startpar on Debian), will happen sequentially, one script starting after the other, making the whole process slow as each script has to wait for the previous one to finish.
• SysV init does not have access to the PID or the processes it has (indirectly) started. It only reads PIDs and associates them with actual processes in a circumstantial, complicated way.
• For system administrators trying to modify the environment under which a certain process would start, it’s quite difficult with SysV init. (In order to achieve this they will have to modify the init strcipt that is responsible to start the given process.)
• There is certain functionality common to every service that SysV does not implement, but each process would have to implement itself instead, such as “daemonising” themselves (becoming a system daemon), which is an elaborate and long process. Instead of implementing these steps once, SysV requires each process to do the job themselves.
• SysV also leaves certain functionality to external programs and knows nothing about services started by those.

All of the above, and many more design flaws, or rather the outdated system design of SysV, has made the creation of a modern init system long overdue.

Enter systemd

There were many attempts to create an alternative init system, of which systemd is only one of them. Ubuntu used to run its own init system called upstart. Gentoo still uses OpenRC. Other init systems include initng, busybox-init, runit, and Mudur and others.

The reason systemd is a clear winner is that it’s been adopted by most major distributions. RHL and CentOS naturally went the systemd way, as Fedora was the first distro to officially adopt systemd in 2011. But systemd has really become the one init system to rule them all, when Debian 8 officially switched to systemd, bringing Ubuntu and derivatives with it, overcoming Canonical’s (or more precisely Mark Shuttleworth’s) initial opposition towards systemd.

How is systemd different?

• Systemd aims to provide a single, centralized way to handle the init process from beginning to end.
• It starts and stop processes and services while keeping track of their dependencies. It can even start a process as a response to another process’ dependency requirement.
• In addition to start and stop processes during boot time, Systemd can also start any time when the system is up in response to certain trigger events such as when a device is plugged in.
• It also does not require processes to daemonize themselves. Unlike SysV init, systemd can handle services running without having to go through the long process of becoming daemons.
• Unlike SysV init, systemd knows and tracks all processes, including PIDs, and getting information about processes is much simpler for system administrators under systemd.
• Systemd supports containers that are basically isolated service environments without the requirement of virtual machines. This has great potential towards more secure and simpler system designs in the future.

Of course these are only some of the major advantages. For a full discussion on systemd’s advantages, you should read Debian 8’s “Systemd Position Statement”

Controversy

Of course systemd was not welcomed by all. In fact, many have and still do frown upon it, calling it monolithic and cumbersome, some even accusing it of going the “windows way” of having everything centralized. Many argue that it is not “the Linux way”, and certainly systemd does not seem to be in accordance with POSIX standards, and if we consider systemd as a toolkit (beyond just the binary), it is definitely hugae.

Nevertheless, systemd is clearly a step forward, and while it’s not perfect, much of the criticism it has received has been addressed by its original author and developer Lennart Poettering. It definitely is is a much needed advancement and a step up from the old init system. Linus Torvalds, the creator of Linux, does not seem to mind systemd too much, and who are we to argue with “The Creator.”

Conclusion

Having been adopted by all major Linux distributions, systemd is here to stay. Whatever some system admins say for whatever reason, systemd is the future of mainstream Linux, whether individual users like it or not, which, looking at its distinct advantages, is not necessarily a bad thing.

For the average user it brings faster boot times and probably more reliable systems, while in the future distributions adopting it can become more “compatible” with one another. On the user end we will definitely benefit from the more up-to-date and contemporary system design it brings to our desktops.