Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Systemd and the future of init
This is a topic some would argue I've discussed ad nauseum, but I'd like to examine the current state of affairs as it regards systemd. For those who don't know, systemd was a system management system created by Lennary Poettering in March 2010. It was designed to replace the long standing, tried and true System V init used by the vast majority of linux distributions. From its inception to the present day, systemd has brought forth considerable controversy due to its design philosophy along with the often curt interactions between developers and the users. Systemd sought to streamline the management of services and make system task more simple and uniform across distributions. I'd say in this respect that its largely accomplished this goal. However, the ostensible simplicity is a facade as the underlying structure of systemd is far more complicated than any system init system that has existed. Its not just an init system, it has consolidated system logging (journald isn't optional and is binary), cron, at, mount, cryptsetup, getty, udev, login, NTP, and another of other components. Then there are ancillary components such as its own bootloader, dns resolver, network manager, and DHCP client. On top of all of this, there are the littany of bugs that have been pervasive throughout the history of the project, many of which have been taged "won't fix" by the development team. 

To understand the insanity, we need to go back. All UNIX and Unix like systems have a critical component called init. Init is the first process ran on a system and it is responsible for starting up and shutting down the computer as well as managing system daemons and adopting any orphaned processes. The two primary init systems that existed since the inception of UNIX were System V init and BSD init. Both were barebones, simple, and just worked. For the most part, they are similar, but there are some notable differences (i.e BSD init doesn't use runlevels). When linux came around, most distributions adopted System V init, with some opting for a BSD style of init. Eventually, system administrators decided that standard init wasn't old and lacked desirable modern features. Chief among these was the management of daemons; if a daemon dies on System V init or BSD init, it isn't automatically restarted for example. Enter systemd, the supposed panacea that everyone was looking for. They advertised the streamlining of management and cool new features such as socket based activation, dependency based boot, parallel service startup, replacement of those pesky shell scripts with ini configuration files for units, and process segregation via the use of cgroups. These are all features that should be applauded, but systemd has failed on the the most crucial promise of init: stability and simplicity. The scope creep that the project has undergone is excessive and they've far outreached what an init system should. The security concerns are generating great uncertainty in its viability as the backbone of many linux systems (I'll go over this in more detaill in a reply to this post). The good news is that viable alternatives exist.

There already exists a number of modern replacements for System V init that have a lot of the great features of systemd without the cruft. The foremost candidate that could be a reliable systemd replacement is OpenRC. It was originally made in 2007 by the Gentoo Linux developers as a replacement for their gallimoufry of init scripts. Like systemd, it has parallel service start, dependency based, boot, process segregation through cgroups, and other useful service management features. It was orginally designed to sit on top of sysvinit, however, they now provide their own set of init scripts that can be used to totally replace sysvinit. A number of linux distributions use it, such as Gentoo, Funtoo, Alpine, Hyperbola, Artix (basically Arch without systemd), and Parabola Linux (libre version of Arch). It can also be installed with some effort on other distributions. Another alternative is the lightweight runit (I'll likely do a guide for it in the future). It was made in 2004 as one of the first replacements for System V init. It was designed to be lightweight and easy to configure. Its main features are full supervison of daemons (via runsv), a solid logging facility (through svlogd), portability, and lightning fast boot up and shutdown. It was relatively under the radar for the first decade, until an independent linux distribution called Void Linux made the switch from systemd in 2014. Since then, the popularity of the distro has exploded.

In general, systemd looks like its going to stay, but people have grown more and more agitated with the regressions of the project and alternatives have continued to expand. The security issue is hallmark among my concerns personally and warrants a careful examination of what we trust to use, especially on mission critical systems. I'd be glad to hear thoughts more thoughts on this matter!
Great concise write up!
I wonder if there is a possibility of a group of developers forking SystemD to create a more security concise SystemD that doesn't just ignore bugs in the system. I need to read more into the bugs, but that is a major concern due to the fact that a good portion of the internet relies on linux.
(02-25-2019, 03:44 AM)Todd Wrote: I wonder if there is a possibility of a group of developers forking SystemD to create a more security concise SystemD that doesn't just ignore bugs in the system. I need to read more into the bugs, but that is a major concern due to the fact that a good portion of the internet relies on linux.

There was once a project called uselessd that tried to significantly reduce the base of systemd to init and daemon supervision; retaining a lot of the good features, while dropping crap like journald, udev, etc. Unfortunately, its been dead for a while now (2015 I think was one of their last releases).

Forum Jump:

Users browsing this thread: 1 Guest(s)