8 ms·
I don't care for SystemD for the same reasons that I don't like MacOS's init system: it an opaque, confusing mess.
by Esau 10y ago
I don't care for SystemD for the same reasons that I don't like MacOS's init system: it an opaque, confusing mess.
- kalenx 10y agoAs are most Bash init files with InitV... At some point we should consider that the init system as a whole (including the configuration scripts for each daemon) _is_ complicated and often confusing. In this regard, writing something like SystemD to elegantly handle most of the usecases is actually a good idea.
- _red 10y agoBash init files may not be particularly feature rich, but they are hardly "complicated". 90% of every file is boilerplate built around: stop, start, status (after all restart is just stop+start). Proponents of SystemD can make some good points, but trying to claim init.d is complicated comes across as desperate.
- kl4m 10y agoAnd 90% of that 90% has that tiny modification that is a nightmare to debug.
- jstimpfle 10y agoWhat he wanted to say: you can debug since context is very local. (not taking sides)
- lisivka 10y agoUse `set -x` or `bash -x script.sh` to trace shell script execution. Shell scripts are easy to debug.
- eropple 10y agoI call this to drop into an immediate repl at the point of invocation in a language that doesn't hate me (Ruby): require 'pry'; binding.pry This is, in fact, 2017. One might call it the current year. The stone knives and bearskins of shell scripting have not kept apace with, like...anything else in our industry. You might be comfortable with them, but that doesn't make it easy, it means you have frayed countless synapses learning it.
- snuxoll 10y agoYou forget that sysvinit also required fun extras like supervisord to run simple executables because it relied on applications demonizing themselves. Writing systemd unit files for my applications is a breeze compared to the shit I had to do for sysvinit - especially when I factor in apps I DIDN'T write that I need unit files for (teamcity, etc) and there's less surprise with SELinux policy transitions (and unlike most setenforce 0 is not the first thing I run on a server, I work in healthcare and a solid MAC layer is important to me).
- xenadu02 10y ago> Bash init files may not be particularly feature rich, but they are hardly "complicated". Are you trying to make the argument that shell scripts are simple, easy to read, and maintainable? Permit me to disagree.
- lisivka 10y agoYep, they are. Shell is lingua franca for system administrators for whole history of UNIX.
- rodgerd 10y agoWhich one? ash? csh? tcsh? ksh? I don't think you have as much experience with Unix as you would like us to think you do.
- prewett 10y agoWhat do you mean which one? It's /bin/sh. /bin/sh has always been the shell used, because it's the only one guaranteed to be on all unixen. No system ships their init scripts written in ash, csh, tcsh, ksh, or anything besides /bin/sh (except Linux, which may have used /bin/bash, since /bin/sh was symlinked to /bin/bash) You might have made your personal init scripts in some other shell (until you learned about design failures of csh), but I'm willing to bet your Unix distributor did not.
- emmelaich 10y agoI rarely see a bash script more than five lines long which doesn't have at least one bug. If you disagree with me then post an example and I'll show you the bug in it. Also, it's not the 90% that matters; it's the 9% that is difficult and the 1% that is crap.
- pmahoney 10y agoMany comments seem to only compare systemd with SysV init. But there is a whole world of process supervisors out there, particularly in the daemontools[1] family. systemd is a process supervisor plus additional features; sysv init is not a process supervisor (though the "init" program as configured in /etc/inittab is a supervisor). At a minimum, a process supervisor starts processes and restarts them should they exit. Some modern daemontools-family systems with additional features beyond basic supervision that put them in the same category as systemd are nosh[2] and s6-rc[3]. These two systems (and all the daemontools family), in contrast to systemd, are not monolithic, but composed of multiple smaller programs. Notably, they depend on the shell (any script or executable, but traditionally small shell scripts) to perform actions like setting up environment variables, switching to a less privileged user, redirecting output, etc. while systemd has created a large and growing set of directives[4] to accomplish these. This set of directives is one of my annoyances with systemd. As someone familiar with the shell, I find it annoying to learn yet another language (systemd directives) for expressing the same thing, though I recognize not everyone is familiar with shell. [1] http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html [2] http://jdebp.info./Softwares/nosh/ http://jdebp.info./Softwares/nosh/ [3] http://skarnet.org/software/s6-rc/ http://skarnet.org/software/s6-rc/ [4] https://www.freedesktop.org/software/systemd/man/systemd.directives.html https://www.freedesktop.org/software/systemd/man/systemd.dir...
- rconti 10y agoBinary logs, hex logs, there's enough stupidity to go around!
- problems 10y agoWhat about runit? Unlike all of the above, runit isn't complicated. You write a tiny, often one-line script and it executes, if it exits, it waits a reasonable amount of time and restarts it. Not only is it not complicated, but it runs beautifully on top of an existing init system. So now wherever I go I have one tiny script that will start my python based web services and similar. I run the same basic script on freebsd rc, ubuntu upstart and arch systemd boxes.
- digi_owl 10y agoWatch the special case directives grow until you can use systemd to implement Conway's Game of Life...
- aaronky 10y agoI 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.
- jcrites 10y agoI 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 <1024, then as the administrator I can take those away with CapabilityBoundingSet= in the unit file. Chrooting the service is as easy as RootDirectory=. This is a huge step forward compared to the world where every service must be relied upon to expose these settings, and must be trusted to implement them correctly. [1] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html [2] https://news.ycombinator.com/item?id=13359519 https://news.ycombinator.com/item?id=13359519
- seanp2k2 10y agohttp://www.soma-zone.com/LaunchControl/ http://www.soma-zone.com/LaunchControl/ Disclosure: I liked this so much that I gave the developer money.
- emmelaich 10y agoPoettering and crew have written an enormous number of excellent blog articles and a great amount of very good manual pages. So, not sure what you have to do to not be 'opaque'