Systemd Sucks, Long Live Systemd

I don't care for SystemD for the same reasons that I don't like MacOS's init system: it an opaque, confusing mess.

I hated systemd when I had to start using it. It tries to do way too much. The antithesis of the the Unix philosophy. Journalctl grew on me though.

I don't know if I'm just crazy but I did enjoy working with upstart for the brief time that I did, much more so than systemd or initv.

I think systemd needs to do most of the things it does. Russ Allbery's analysis of systemd [1], written as part of Debian's evaluation of whether to switch to systemd, explains the benefits. Journal integration is something that Russ was also skeptical about, until he realized its value:

  * Integrated daemon status.  This one caught me by surprise, since the
    systemd journal was functionality that I expected to dislike.  But I was
    surprised at how well-implemented it is, and systemctl status blew me
    away.  I think any systems administrator who has tried to debug a
    running service will be immediately struck by the differences between
    upstart:
  
    lbcd start/running, process 32294
  
    and systemd:
  
      lbcd.service - responder for load balancing
       Loaded: loaded (/lib/systemd/system/lbcd.service; enabled)
       Active: active (running) since Sun 2013-12-29 13:01:24 PST; 1h 11min ago
         Docs: man:lbcd(8)
               http://www.eyrie.org/~eagle/software/lbcd/
     Main PID: 25290 (lbcd)
       CGroup: name=systemd:/system/lbcd.service
               └─25290 /usr/sbin/lbcd -f -l
  
    Dec 29 13:01:24 wanderer systemd[1]: Starting responder for load balancing...
    Dec 29 13:01:24 wanderer systemd[1]: Started responder for load balancing.
    Dec 29 13:01:24 wanderer lbcd[25290]: ready to accept requests
    Dec 29 13:01:43 wanderer lbcd[25290]: request from ::1 (version 3)
  
    Both are clearly superior to sysvinit, which bails on the problem
    entirely and forces reimplementation in every init script, but the
    systemd approach takes this to another level.  And this is not an easy
    change for upstart.  While some more data could be added, like the
    command line taken from ps, the most useful addition in systemd is the
    log summary.  And that relies on the journal, which is a fundamental
    design decision of systemd.
  
    And yes, all of those log messages are also in the syslog files where
    one would expect to find them.  And systemd can also capture standard
    output and standard error from daemons and drop that in the journal and
    from there into syslog, which makes it much easier to uncover daemon
    startup problems that resulted in complaints to standard error instead
    of syslog.  This cannot even be easily replaced with something that
    might parse the syslog files, even given output forwarding to syslog
    (something upstart currently doesn't have), since the journal will
    continue to work properly even if all syslog messages are forwarded off
    the host, stored in some other format, or stored in some other file.
    systemd is agnostic to the underlying syslog implementation.

I wrote another comment recently [2] to explain why I value systemd's approach and appreciate its declarative style. I can launch my service at the appropriate time during boot with configuration as simple as:

  [Unit]
  Description=Demo service

  [Service]
  Type=forking
  ExecStart=/usr/sbin/my-daemon

Now let's say that I didn't author this daemon, but I'd like to run it with a private network, private temp folder, or a private /dev namespace. Or perhaps the daemon needs to run as root, but I want to drop all capabilities it doesn't need. It's as simple as adding these lines to the service's configuration:

  PrivateTmp=yes
  PrivateDevices=yes
  PrivateNetwork=yes
  CapabilityBoundingSet=CAP_NET_BIND_SERVICE

The fact that systemd supports these configuration options means that there's a simple and standard way to employ them with any service. The service itself doesn't need to support them, and needn't complicate its own daemonization logic to do so correctly. Indeed, I don't need to trust the service to daemonize or drop capabilities, since I can tell the init system do that before launching the service.

I can drop capabilities with CapabilityBoundingSet=, or limit resource usage with CPUSchedulingPriority=, IOSchedulingPriority=, etc. I could even tell systemd to open the listening socket for me so the service doesn't need CAP_NET_BIND_SERVICE! Moving these options into the init system makes a ton of sense, because it gives administrators the ability to employ these features from outside applications, not just by enabling them within applications that bother to explicitly support them via command line arguments. Systemd better encourages the principle of least privilege: if a system daemon does not need the ability to "ptrace" other processes, or bind to ports [1] https://lists.debian.org/debian-ctte/2013/12/msg00234.html

[2] https://news.ycombinator.com/item?id=13359519

I feel like at some point, news aggregation sites will need moratoriums on this topic. Systemd is an architectural decision with very philosophical effects, so by its very nature be very divisive. I'm, personally, not a fan at all of systemd, but am tired of seeing these stupid arguments everywhere all the time.

There are plenty of places to find competent summaries of both the technical and political arguments for and against systemd and we don't need yet another.