[barrkel]

Init-scripts are a bunch of file system conventions and shell scripts; it's an imperative way of bringing a system into a particular state (networking, services etc.). Init itself is the very first process the the OS executes; all processes in -nix are created by forking. When using init-scripts, init is extremely simple.

Systemd replaces init and uses a declarative approach for the system and its services, and the dependencies between the services (replacing init-scripts). Systemd is more complicated but can do more stuff, like initialize things concurrently. Functionality that used to be implemented in services themselves (e.g. restarting, recovery) is migrating into systemd, and systemd is acquiring more and more logic. Some people feel that this is contrary to the *nix philosophy and is not architecturally sound.

Operationally, instead of using shell scripts and symlinks designed to be sorted in a particular order (normally maintained using other tools), you use descriptions of how the service should start and what it depends on.

Security-wise, systemd is a bigger hairier ball, so it probably has bugs. But it also implements stuff once, whereas before implementations were distributed and of variable quality. So the variance in security level is probably lower with systemd, but depending on your mix of services, the mean may be higher or lower. And you don't get to control it.

[rleigh]

You've made the mistake of assuming that the old system couldn't start up stuff in parallel. That's simply not true; Debian had insserv/startpar to create a global dependency graph and run the scripts in parallel while satisfying all dependency constraints.

(As an ex Debian developer myself, I spent many many hours working on this stuff while I was one of the sysvinit maintainers.)

[jcrites]

One of the most informative writings I've read on the topic of systemd and its benefits and comparison with other tools was written by Russ Allbery, which explains his contribution to Debian's choice to adopt it [1]:

> I did a fairly extensive evaluation of both upstart and systemd by converting one of my packages[] to a native configuration with both systems. []I tried to approach each init system on its own terms and investigate what full, native support of that init system would look like, both from a Debian packaging perspective and from an upstream perspective. I also tried to work through the upgrade path from an existing init script with an external /etc/default configuration file and how that would be handled with both systemd and upstart.

> I started this process with the expectation that systemd and upstart would be roughly evenly matched in capabilities. My expectation was that I would uncover some minor differences and variations, and some different philosophical approaches, but no deeply compelling differentiation.

> To my surprise, that's not what happened. Rather, I concluded that systemd has a substantial technical advantage over upstart, primarily in terms of available useful features, but also in terms of fundamental design.

The essay goes on to elaborate on the details. I personally found this and other writings a compelling argument in favor of the approach. Another useful article was "Why systemd?" [2]. There's also the blog post series "Systemd for Administrators" [3].

What systemd strives for makes a lot of sense to me. It allows you to describe the startup of services with declarative configuration in a simple and easy-to-understand format. Systemd is natively integrated with OS namespaces, cgroups, and the process hierarchy. Russ gives an example in his essay of how this allows systemd to track and display more information about daemons than the alternatives. It might be more complicated than the alternatives in one sense, but that buys you the power to do things like: activate services on-demand, when requested by a client; automatically launch services per user session, and clean them up on logout; concurrently start services for a fast boot; consign managed services to an OS namespace. By supporting these features in the init and process management system, it frees individual services from redundantly building this logic in their shell scripts and daemonization routines. That reduces complexity, and makes the entire system more feature-rich, more secure, and easier to manage.

As far as security, systemd makes it substantially easier to employ kernel namespace, cgroups, capabilities, and other isolation facilities with simple configuration switches. Let's say that we'd like to run some daemon with a private /tmp directory for isolation. This is as simple as adding "PrivateTmp=yes" to its configuration. What if we want to change the run-as user, or even launch the service in an isolated user namespace? Perhaps we want the daemon to have a private network or private /dev? It's as simple as setting User=, PrivateUsers=, PrivateNetwork=, PrivateDevices=, etc. respectively:

  [Unit]
  Description=Demo service

  [Service]
  Type=forking
  ExecStart=/usr/sbin/my-daemon -d
  User=foo
  PrivateTmp=yes
  PrivateUsers=yes
  PrivateNetwork=yes

Take a look at all the options you can apply in [4]. CPUAffinity=, CapabilityBoundingSet=, IOSchedulingPriority=, etc. It's great to be able to set all of these options in a single consistent place for all daemons.

[1] https://lists.debian.org/debian-ctte/2013/12/msg00234.html

[2] http://blog.jorgenschaefer.de/2014/07/why-systemd.html

[3] https://gist.github.com/bcremer/8cdf6900c35dda65f387

[4] https://www.freedesktop.org/software/systemd/man/systemd.exe...

[JdeBP]

It is an interesting contrast with the Arch decision process that occurred.

* https://news.ycombinator.com/item?id=11834348

[Z-Widwil]

Thank you for the informative and neutral response. I knew there was a larger debate over the two, but I didn't have a good enough understanding of the two to know why.

[JdeBP]

You still have not. (-:

barrkel talked about systemd as a replacement for init, but that's not the goal of its authors. Nor was there a debate over the two.

There was a debate in Debian Land over at least four choices: systemd, upstart, OpenRC, and sticking with van Smoorenburg rc with Debian's various enhancements.

The stated goal of the systemd authors pretty much from the start was not to "replace init", or even to replace both init and rc. What barrkel wrote could be said of daemontools from 1997, after all. That, too, encouraged a move of common procedures and mechanisms out of bespoke daemon programs and scripts and into a common daemon management system.

systemd, rather, was to provide a common layer, beneath everything else and above the kernel, used on all Linux operating systems. Its authors saw the differences such as /etc/sysconfig/network versus /etc/HOSTNAME versus /etc/hostname versus /etc/conf.d/hostname and wanted to unify all that, so that all Linux distributions worked the same. They didn't just write process #1 program. They wrote a name-lookup server with a local protocol to replace the DNS protocol (and the protocol that GNU libc uses to talk to its lookup helper processes), a network interface setup/teardown utility, a whole bunch of service utility programs such as a program to save/restore randomness from /dev/urandom across system restart, a centralized log writer, a centralized login session manager, and a whole bunch of programs that provided RPC interfaces, over a centralized system-wide Desktop Bus instance to GUI tools running on user/administrator GUI desktops, for things like setting the default timezone and pretty-print hostname. To that they added rules about where to find different sorts of stuff, from administrator-written unit files to /etc/machine-id; guarantees about "API filesystems"; rules about /run, /run/user, and a whole bunch of related memory filesystems; deprecation of things like /var/run/lock; rules about what sockets old syslog programs had to change to using, in place of what they had been; per-user service manager instances and a whole extra set of PAM hooks that connected it with the new runtime directories and the login session manager; and requirements such as that /usr be already available at the point that /sbin/init is invoked from the initramfs. They got some additions made to Linux in support of this, such as subreapers; and failed to get others, such as kdbus.

"systemd replaces init" is both superficial and a blinkered Debian world-view. In the world outwith Debian, in Ubuntu Land and Fedora Land, systemd replaced upstart, which had been the Fedora and Ubuntu system and service manager for a number of years before systemd was invented. The world has never been van Smoorenburg rc scripts versus systemd, not even when the whole Debian debate was had.

* http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html

* http://blog.darknedgy.net/technology/2015/09/05/0/

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

[rodgerd]

This is probably one of the better-quality neutral write-ups I've seen.