19 ms·

Systemd Sucks, Long Live Systemd

208 points by naftulikay 10y ago

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 ago
  As 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 ago
    Bash 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 ago
      And 90% of that 90% has that tiny modification that is a nightmare to debug.
      - jstimpfle 10y ago
        What he wanted to say: you can debug since context is very local. (not taking sides)
      - lisivka 10y ago
        Use `set -x` or `bash -x script.sh` to trace shell script execution. Shell scripts are easy to debug.
        eropple 10y ago
        I 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 ago
      You 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 ago
        Yep, they are. Shell is lingua franca for system administrators for whole history of UNIX.
        rodgerd 10y ago
        Which 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 ago
        What 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 ago
      I 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.
      - ktRolster 10y ago
        There's this example for your approval: https://news.ycombinator.com/item?id=13388322 https://news.ycombinator.com/item?id=13388322
        emmelaich 10y ago
        The reply from bazurbat covered it well.
  - pmahoney 10y ago
    Many 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 ago
      Binary logs, hex logs, there's enough stupidity to go around!
  - problems 10y ago
    What 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 ago
    Watch the special case directives grow until you can use systemd to implement Conway's Game of Life...
- aaronky 10y ago
  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.
  - jcrites 10y ago
    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 <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 ago
  http://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 ago
  Poettering 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'
pkaye 10y ago
One of the things I like about systemd is you can get a graph of the boot time along with critical path via the following: systemd-analyze plot >boot.svg
awinder 10y ago
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.
- nictrix 10y ago
  I agree, Upstart was great for most things and was simple to understand. Though I ran into some difficult fork, exec issues for certain processes. I sometimes had to run a wrapper to use upstart, but those seemed to be edge cases. I'd prefer if we stuck with Upstart and improved on it, though it already seems like a distant dream.
  - digi_owl 10y ago
    I sometimes wonder if edge cases are inherently fractal. take care of one and two more spawn. Thus when i see some dev talk about exorcising edge cases because of user friendliness i see them preaching a fools errand.
Karrot_Kream 10y ago
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.
- djsumdog 10y ago
  I don't feel they should. These are arguments I haven't heard before either and I'm glad to see more of these weird cases laid out. I run Gentoo (OpenRC) and Void (Runit) on my own systems, and although I do like both of them, I find the total lack of alternatives to the systemd ecosystem troubling. As a package maintainer, I do like being able to create rpms/deb files and only needing one standardized init script, so there is are a few advantages to systemd, but not many. It's complexity makes it difficult to create drop in replacements (work has stopped on uselessd and others). There needs to be more community support for distros like Void and real alternatives. Articles like this encourage that kind of thinking.
  - lisivka 10y ago
    Why not to write generator of init scripts from Systemd unit files? Unit files are well documented for typical options and are easy to write.
    - JdeBP 10y ago
      Ahem! * http://jdebp.eu./Softwares/nosh/worked-example.html http://jdebp.eu./Softwares/nosh/worked-example.html * http://unix.stackexchange.com/a/200281/5132 http://unix.stackexchange.com/a/200281/5132 * https://www.mail-archive.com/supervision@list.skarnet.org/msg01227.html https://www.mail-archive.com/supervision@list.skarnet.org/ms...
  - microcolonel 10y ago
    Where systemd is complex, it's because the use case is complex. If you know so much about these use cases, and you think systemd is unnecessarily complex, why don't you do it yourself and see where that takes you?
deleted 10y ago
[deleted]
FeepingCreature 10y ago
I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency handling. https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.gentoo.org/wiki/Comparison_of_init_systems > OpenRC provides a number of features touted as innovative by recent init systems like systemd ...
- ashark 10y ago
  OpenRC's the only init system I've actually liked. It's one of the things I really miss from when I used Gentoo, and I don't know why more distros didn't adopt it years ago.
  - ausjke 10y ago
    probably it is not related to technical, SystemD has Redhat in the back initially I think.
  - dijit 10y ago
    You should check out SMF, if you have a couple of hours to play with Solaris.. it handles things that systemd does (socket activation, process management/watching etc;) but in an orthogonal way that makes sense. I like openrc, I also like runit (for different reasons) but SMF is the gold standard for me and I recommend more people check it out. Even if it has XML elements :(
  - JdeBP 10y ago
    TrueOS has just switched from Mewburn rc to OpenRC. They've had some problems to overcome.
  - johnny22 10y ago
    OpenRC was definitely my favorite init system before systemd existed. Definitely beat out the defaults of distributions who were using the debian/redhat style sysvinit.
- edoceo 10y ago
  I'm on Gentoo and remember the switch to OpenRC. I was nervous. But all the old stuff worked! And my custom init scripts? Changed only one or two lines to make them work and a few more edits to make them fully OpenRC like. Backwards compatible FTW! And, now with OpenRC it still "just works". Fast, predictable boot with logs in normal places that I can easily debug, manage and modify.
colemickens 10y ago
Why would you run the Exec command through systemd-escape? The help text says that's for the NAME of the unit... Am I missing something? Also, I'm failing to think of a scripting purpose that requires you to place non-trivial bash directly in a systemd unit that couldn't be solved by writing out the script somewhere and just invoking the script in the unit.
- chungy 10y ago
  > Am I missing something? You're not. Contrived example is contrived.
- naftulikay 10y ago
  > Now agreed, if your workflow demands that you embed a Bash while loop in a unit, you’re already in a bad place, but there are times where this is required for templating purposes. It's right there in the post. I have indeed had to do something like this in the wild to run a Docker container with special needs.
  - admsyn 10y ago
    Both you and OP haven't mentioned why you needed to do it inline as opposed to in an external script, though.
  - colemickens 10y ago
    I don't see how "templating purposes" answers the question. I deploy services on VMs that need to parameterized and I can parameterize via templating a written-to-disk shell script that is then just simply executed in the unit... or I can have more dynamic parameterization and use environment variables and Environment= lines in the unit. The latter solution means the substitution is effectively happening in the same place as if they were inlined parameters, so I can't imagine a scenario when it wouldn't be workable.
agumonkey 10y ago
Systemd ideas I'm all for but it only hints at linux lack of clean abstraction power. sysvinit was full of redundancy; apparently BSD found a way to make a thin abstraction layer to make init files clean. Bash isn't "good" at hinting proper abstractions, I rarely see talks about this, maybe gurus can see through the rain. I keep seeing a place for a tiny lambda friendly intermediate layer .. Just so you can compose properties of your services like clojure ring middleware. (-> (path "/usr/bin/some-service" "arg0" ...) (wrap :pre (lambda () ...) :post (lambda () ..)) (retry 5) ... (timeout 5)) Is this ugly to your eyes ? ps: the idea is that (retry 5) is a normal language function, and not a systemd opaque built-in, you can write your own thing, and the most used can go upstream. Hoping to avoid the sysvinit fragility and redundancy.
- djsumdog 10y ago
  Have you looked at the runit init system? Here is /etc/sv/sshd/run on void linux: #!/bin/sh ssh-keygen -A >/dev/null 2>&1 # Will generate host keys if they don't already exist [ -r conf ] && . ./conf exec /usr/bin/sshd -D $OPTS Service scripts are dead simple on Void.
  - agumonkey 10y ago
    Where do you specify laziness, failure policy etc ?
    - hedora 10y ago
      Why would I specify those in an init script? openssh has been doing The Right Thing(TM) for about two decades. Also, openssh has protocol-specific (and secure by default) configuration options around connection lifecycle, etc. that no general purpose init system should try to replicate and then blindly apply to unrelated services.
      - geofft 10y ago
        OpenSSH is the unusual case. Most the the services I run don't do the right thing. That's why, for instance, Debian wrote the start-stop-daemon utility years before anyone ever dreamed of systemd. I've been greatly enjoying systemd for the ability to write services and startup jobs in languages that don't have great libraries for doing all the right things, like Python and shell, because it gives me all those Right Things as effectively a library. I don't have to manage pid file handling and daemonization and restarts on my own; systemd will do it, and will do it well and Right. (I used to do this with start-stop-daemon, and it did it poorly and only okay.) It will also get out of the way of OpenSSH, which does it well and Right, and get in the way of the dozens of services that think they're doing it well and Right but aren't. Easy things should be easy, and hard things should be possible. systemd supports both. If that's the extent of what runit can in fact do, it only supports the former. (SysV-style init, of course, just makes easy things hard and hard things confusing, but as everyone else is saying, it's very not the standard of comparison here.)
baybal2 10y ago
Systemd is an init written by a terminal stage architectural astronaut
CaptSpify 10y ago
I'll put my opinion in the middle ground with systemd as well. I like a lot about it, and I dislike a lot about it. I really think the best thing they could have done would have been to make it modular. If people could just turn off the "features" that they don't want, there wouldn't be so much bitching about it. Instead they keep trying to shove everything into one giant pile, and don't understand why people get upset.
- srslack 10y ago
  You'll find that there's pretty much nothing you can't outright disable, except for journald. journald needs to be running, but you can turn off the binary logging and redirect everything to syslog. systemd itself is a collection of system daemons, as well as small programs to interact with those daemons, and almost all of them are disabled by default. That's my experience on Arch, and they adhere strictly to upstream defaults. If that weren't enough you could simply leave out the daemons you don't like at compile time.
  - JdeBP 10y ago
    > you can turn off the binary logging Every time that people write that they tell other people who do know systemd that they do not know it. The journal cannot be turned off. Making it be stored in files in /run/log/journal/ instead of in files in /var/log/journal/ is not turning it off. It's making it non-persistent so that it doesn't last across system restarts, delegating the job of writing persistent logs to post-processing services that (nowadays) read the journal using its systemd-specific database access facilities. Ironically, making it not be stored in any files at all would actually prohibit the post-processing services from working, as they would have nothing to read and to process into their own formats. * http://unix.stackexchange.com/a/332315/5132 http://unix.stackexchange.com/a/332315/5132
    - srslack 10y ago
      >they tell other people who do know systemd that they do not know it. I appreciate the concern, thanks. >The journal cannot be turned off. The persistent binary logging is turned off, which is what people bitch about. Obviously, many of systemd's monitoring features are tied to the journal, and as stated journald still needs to be running, obviously writing to a non-persistent journal for these and forwarding logs (if specified.) >delegating the job of writing persistent logs to post-processing services that (nowadays) read the journal using its systemd-specific database access facilities. It's true that syslog-ng pulls messages from the journal, whereas syslog implementations that are not aware are provided with them over a compatibility socket, but this is a performance optimization, to reduce system overhead. Not really an important distinction. The context was turning persistent logs off and switching to on-disk and persistent text logs with syslog. If you really wanted to nitpick: dbus and udev are totally non-optional.
Sir_Cmpwn 10y ago
I've found runit to be the best (but not perfect) as far as init systems go. Check it out.
weberc2 10y ago
> Admittedly, it requires an environment file I know almost nothing about systemd, but you can define environment variables inline instead of in a file: `Environment=ENV_VAR=value`.
ausjke 10y ago
The sad thing is, you do not really have a second option, yes I know some distros say they have alternatives, but SystemD becomes the "preferred" init system nearly everywhere now. I just hope Debian to get rid of SystemD and return to whatever else. I know I'm biased, just failed to find a reason to love SystemD, tried a few times.
- hedora 10y ago
  I've found that devuan is a joy to use on my laptop. I'm also rotating BSDs and open source solaris variants on to the home network machines. (Switching to solaris to get rid of systemd would be overkill; I switched to joyent triton for better containers and zfs...)
  - ausjke 10y ago
    Devuan has jessie in beta now, at the moment I have not given up on linux yet, am going to try Devuan.
alyandon 10y ago
At first I didn't care much for the idea of having to learn yet another init system but as I had to write ansible automation stuff for services on Centos 7 it was kind of required that I have some basic understanding of systemd. I have to say now that I'm more familiar with it it has begun to grow on me. There is something subjectively nice to me about running systemctl status and seeing a nice, clear picture of what the current state of services are on a system, being able to control the life cycle of a service including having systemd monitor and restart it, not having to deal with improperly written init scripts, etc. Stockholm Syndrome perhaps?
- jcrites 10y ago
  Russ Allbery's investigation [1] into alternative init systems, in the Debian's project to select the best one, also viewed this systemd property in a similar way -- a surprising and unexpected benefit. Systemd's native understanding of cgroups, process hierarchy, and logging makes this view possible. [1] https://news.ycombinator.com/item?id=13387989 https://news.ycombinator.com/item?id=13387989
- astrodust 10y ago
  The idea of systemd isn't bad. What's annoying is the friction involved in using it. It's just a shade too ornate, a little too magical, in both cases only by a small degree, but it's an important one. Creating a workable systemd init script is actually pleasant. Getting it running is easy. Checking for errors with status is nice, but searching the logs is annoying. pm2 (https://github.com/Unitech/pm2 https://github.com/Unitech/pm2) has a neat feature where you can watch logs easily, someting that systemd should totally steal and pack into journalctl, like "systemctl logs sshd" shows it in real-time, an alias to the obnoxiously verbose "journalctl -u sshd -f"
  - nvarsj 10y ago
    I'm not sure how you could write this with a straight face. Systemd has friction, but writing init scripts doesn't? Are you kidding me? Have you ever had to write init scripts for production servers? Writing systemd unit files is entirely more straightforward and simple than any init script hackery. And how is "journalctl -u sshd -f" not straightforward? Systemd has its issues sure, but your comment is pure FUD.
peterwwillis 10y ago
The problem with systemd is not that it is "bad". There's a lot worse software out there. Systemd is relatively competently programmed. And it's even useful! The problem with systemd has always been that it forces you to do everything the systemd way, and usually to use its tools. It goes against everything that has helped GNU/Linux become a great system: that it wasn't really one system. It was bits and pieces, and you could add them together however you wanted to get something you liked. Systemd is the opposite. It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. I can compare it to Windows, but I feel like that would be an insult to Windows' usability. If this one single fact was different, everyone would love systemd, because it has plenty of useful features. But because it is designed specifically to please a single quirky user, people hate it.
- jcrites 10y ago
  > It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. Could you share a few specific examples? That hasn't been the case at all for me. I have worked with systemd and have had the opposite experience. I simply write textual config files describing how to launch the service, which can be done in a variety of ways. Could you share more about how you tried to use systemd? I'd encourage you to read Russ Allbery's analysis of systemd [2], which includes a description of his experience converting one of his packages to use systemd. He remarks on the well-done integration and its compatibility: * 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 think Russ's passage exhibits the opposite sentiment from the one you wrote. Russ says you can get the benefits of systemctl and journalctl if you want, but you can also use syslog in the old-fashioned way if you want. This has been my experience with systemd as well. I still have a habit of writing "service postfix restart", which still works but is not the systemd-idiomatic way. I don't even have the "correct" way memorized because the old way that I'm used to using works. So what I'm asking is, have you tried to achieve something with systemd and found that you were forced to do it differently? I'd be curious to learn more about what those cases were. I'm not affiliated with systemd project, but I have a general interest in wanting to see it improve. (Please note that, barring conventions of some kind that span multiple tools, every tool naturally requires you to do things that tool's own way. If you are holding systemd to the standard that its job should be able to be performed by two different tools, each with the same interface, while supporting advanced features, then you should have other examples of this as well.) [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... [2] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html
secabeen 10y ago
I've never particularly liked init systems that restart jobs when they die. Normally, I don't want daemons that crash to restart. They should die, be caught by monitoring and the server bypassed. I would accept a single restart but after that, there's clearly a problem, and the systems should fail, rather than restarting the process again and again and again.
- plorg 10y ago
  As a single user with a number of personal/hobbyist machines, I actually find systemd annoying to work with for precisely this reason. If a daemon is misconfigured and fails to launch several times in a row, it inevitably triggers the systemd "too many retries" error, after which systemd will refuse to start the daemon until some timeout has expired or the counter is cleared. This makes troubleshooting more difficult and frustrating.
  - kinghajj 10y ago
    Funnily enough, just dealt with a bug caused by this at work. The small PC would boot before the cellular modem had an Internet connection. Services that communicate via MQTT would immediately attempt to reach the broker, and throw an exception. My quick fix was just to add "RestartSec=5" so that the faulted state would never be entered.
    - kasabali 10y ago
      Ironic considering how systemd developers brag about eliminating race conditions and sleep calls from init scripts.
digi_owl 10y ago
More and more systemd is becoming symptomatic of deeper divide within the Linux "community". The split being between those that embraced Linux for being a free, in both senses, _nix unburdened by AT&T and running on commodity hardware, and those that got to know it after the dot-com crash as the L in LAMP. The former cares for Linux as a _nix, the latter could not care less about _nix and may see it as a vestigial appendage that should have been amputated long ago.
- AnonymousPlanet 10y ago
  I'm not so sure if it really has that much to do with heritage. A lot of us like the design principles you can see in Unix and that are pretty much absent in systems like Windows NT. They very much reflect the conclusions I came to after over fifteen years of building and debugging systems. But, yes, I have the impression that a lot of Linux users would just as gladly use a modern BeOS or a ReactOS, regardless of the underlying design. And a lot of systemd criticism comes from people who are just averse to any kind of change and maybe long for the bygone days of HP-UX and Irix.
  - digi_owl 10y ago
    There is change and there is change.
- vidarh 10y ago
  No, it's symptomatic of most of the Linux community having embraced systemd, and the holdouts being few and far between.
- teddyh 10y ago
  Let me just say that I disagree: I am squarely in the former camp – I started with SunOS 4 in 1992, learned to use the Internet before the WWW, and am a long-time GNU advocate, and I am also a professional system administrator. I like systemd just fine. In fact, I started using it at home and at work just as soon as the package became available in Debian 7 (wheezy). I think, however, that you have a point in that some people ascribe some mystical properties to the design of _nix and _nix-like systems. I have never done this, perhaps because I remember the early days of OS/platform wars (Amiga or Atari? PC or console? Unix or VMS?), first on BBSes, then on Usenet. I also, early on, read the Unix-Haters Handbook, and I found it enlightening, even though it is not always spot-on. I leave all die-hard advocates with this quote: “All Software Sucks, All Hardware Sucks” (http://www.absurdnotions.org/an20010622.gif http://www.absurdnotions.org/an20010622.gif) (Source: (http://www.absurdnotions.org/page75.html http://www.absurdnotions.org/page75.html). Start of storyline: (http://www.absurdnotions.org/page74.html) http://www.absurdnotions.org/page74.html))
sebcat 10y ago
> The justification for storing logs in a binary format was speed and performance, they are more easily indexed and faster to search. Are there any benchmarks for this? I don't know why, and I may be doing things wrong, but journalctl -lu <unit> --since yesterday in our prod env takes a couple of seconds before I see any output, while a (z)grep on a date rotated, potentially compressed log file on a non-journald system is generally instantaneous. On a side note, I really like machine parsable, human readable logs, and I've never had any speed or performance issues with it when dealing with volumes of hundreds of millions of log entries, though that may be because I don't know any better.
- flukus 10y ago
  My question would be "is searching worth optimizing for anyway?". Log files are typically only read when things go wrong or by automated systems where a few seconds here or there doesn't make much of a difference. Faster to search often means slower to write too, I'd prefer faster to write and slower to search if I had to choose.
- gens 10y ago
  Of course nobody benchmarked. Rarely are there programmers in OSS these days that benchmark anything. (not nearly as common as those who claim "speed") There was a bug though where the journaling was so slow it caused the whole server to crash. (sorry, can't find it right now; something about them using mmaped files and the access pattern was.. or something, interesting stuff:) Binary logs should be faster, in theory, and should/could be as robust as text logs (if not more), in theory. edit: note that GNU grep is insanely optimized.
  - pif 10y ago
    > Rarely are there programmers in OSS these days that benchmark anything. Please, don't release such a bold statement without any source. Please!
    - yjftsjthsd-h 10y ago
      How would you cite the lack of testing? GP did discuss several regressions that imply performance wasn't thoroughly tested.
krylon 10y ago
At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it's problematic that it is so Linux-centric and will cause problems maintaining software to run both on Linux/systemd and on *BSD. The way it was pushed on distros was problematic, in my opinion. But having used a couple of Linux systems running systemd - Raspian Jessie and openSUSE - I have to admit it's not that bad. In practice - on laptops and desktop systems (assuming one counts the Pi as a desktop system; for my use case, I do) - I had no problems with it. Enabling and disabling services is a lot easier. I do not think is as great as its proponents claim, but it's not as bad as some people think, either. Personally, I have come to appreciate journald, even though I still agree that binary logs are a bad idea. At least there is still the option of installing a syslog daemon.
- digi_owl 10y ago
  Some parts may be useful, some parts are downright awful, but the clincher is that it is all a big wadded up ball of code. Damn it, the LFS team basically adopted eudev, of Gentoo fame, because extracting udev from systemd required manual intervention over and over.
  - noinsight 10y ago
    > a big wadded up ball of code. To be clear, they're all under the same umbrella project, but separate components and not everything is in PID 1. People seem to be confused by that.
    - digi_owl 10y ago
      Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.
      - krylon 10y ago
        OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.
svennek 10y ago
Most people I hear having problems with Systems is either on Redhat or Debian - not realising the both are mangling systemd badly. RHEL took in systemd way too early and are missing a lot of needed functionality. Also the have an ungodly amount of patches on top - so much you could argue it should be named redhatd instead. Debian just chooses to take the worst possible middle position due to politics. All of the disadvantages from systemd, but not really any of the great stuff as systemd units often just start shellscripts due to compatibility.... If you want to try systemd in all its glory try Arch or something downstream from it... I for one think that systemd has made my admin-life so much better ..
- AstralStorm 10y ago
  I am running systemd on Gentoo. (like Sabayon) While some of the features are nice, it is a royal pain to upgrade due to intertwined deps and forced restarts. And it doesn't do anything OpenRC couldn't do, in fact its journald is a pain which had to be worked around. OpenRC way of doing socket activations and dbus activations also works slightly better (in case something crashes) It does parallelism just as well, service dependencies too. Gentoo does not mangle anything related to systemd unlike the mentioned distributions.
  - svennek 10y ago
    Yeah, Gentoo is quite nice in that regard, but isn't it still focussed on openrc? I was a ten plus years gentooo user before I switched to Arch (mostly because I got fed up with compiling)
    - jakeogh 10y ago
      OpenRC is the first option in the install guide, but you can choose systemd. I cant think of a good reason to do so.
nvarsj 10y ago
I get the feeling anyone who complains about systemd is just a hobbyist jumping on a hate bandwagon. For anyone who manages production systems, systemd is a godsend compared to the homegrown-per-distro shell based init systems.
- msimpson 10y ago
  Did you actually read the article or just these comments?
tannhaeuser 10y ago
Best thing of systemd is that it's putting people behind alternate systemd-free Linuxen. Devuan, Alpine, Gentoo, Void (and particularly the BSDs) come along nicely. I can tolerate systemd on desktops as long as I don't have to deal with it. The moment it craps out with Java-esque error traces in binary logs I'll install Slackware (or is there a modern desktop Linux without systemd I'm not aware of?). Other than for desktops with complex run-time dependencies (WLAN, USB devices, login sessions), what are the benefits of systemd for servers that warrant a massive, polarizing, tasteless monolith which puts you up for endless patches and reboots, especially in a container world? (Re-)starting and stopping a daemon isn't rocket science; it's like 10 lines of shell code.
- dijit 10y ago
  SystemD was so polarizing for me, I was a Fedora user and RHEL user for work- but it started consuming everything and giving really bizarre issues... I tried reaching out and explaining to people that it wasn't working in the way I expected or, asking them to point me towards the docs so I can at least learn how to use journalling properly so it doesn't hide issues from me.. and was met with some hostility. When I asked to disable binary logging entirely because it kept getting corrupted and was opaque I was met with "Unlearn your old ways old man"-style responses and "You can just log to rsyslog too".. No, I want it disabled.. I don't have a desire to log twice.. It was then I realised I was at the mercy of systemd, they can push whatever and reject whatever and I'm completely out of control- I cannot introspect their service manager effectively, it's non-deterministic. It just reeks of hubris from the maintainers. It does mostly the right thing for most people, and they compare it to sysvinit which admittedly needed love. (and, was not a process manager, was only a process starter). So, I adopted *BSD on the server. And christ is it wonderful. I still use Arch/SystemD on my desktop at home, because it's actually pretty useful on laptops/desktops. But I swore a vow never to manage a server with SystemD on it. I'm still runing RHEL6 at work, for the next OS, I'm pushing my very large corp to adopt FreeBSD as an alternative. That's a fairly large amount of money that Red Hat will lose and I don't particularly feel bad about it. They forced my hand.
  - tannhaeuser 10y ago
nailer 10y ago
Does systemd have a network protocol like syslog, i.e. is there a native way to send logs for a particular unit/service to a remote machine? Everything I find just says to install syslog, which surprises me.
- JdeBP 10y ago
  Would native actually be your preference, though? Or would you really prefer tools that spoke existing protocols like RELP?
  - nailer 10y ago
    native would be my preference as I'd rather avoid installing any software at all. Protocol will be HTTPS, format will be https://www.freedesktop.org/wiki/Software/systemd/json/ https://www.freedesktop.org/wiki/Software/systemd/json/
- nailer 10y ago
  Actually found what I was looking for (via http://stackoverflow.com/questions/23082512/coreos-systemd-journal-remote-logging http://stackoverflow.com/questions/23082512/coreos-systemd-j...): https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html https://www.freedesktop.org/software/systemd/man/systemd-jou...
z3t4 10y ago
My main complain about systemd is that it does not log the stderr stream !!
- yrro 10y ago
  It does log the standard error stream. The default value of StandardError= is inherit, which will cause stderr to go to the same place that stdout goes, which by defaults to journal. This is documented in systemd.exec(5). If not overriden in an individual service's unit file, perhaps you have set DefaultStandardError= in /etc/systemd/system.conf?
  - z3t4 10y ago
    The problem is that it doesn't store "unit" meta-data for stderr, so you can not see stderr logs with journalctl -u nameOfUnit or systemctl status nameOfUnit
    - yrro 10y ago
      I do not find this to be the case. Right now I'm looking at the journal and observing the existence of _SYSTEMD_UNIT fields for messages that have been written to a process's standard error stream.
      - z3t4 10y ago
        Can you see them when you run journalctl -u nameOfUnit or systemctl status nameOfUnit ? I'm running Ubuntu server.
        yrro 10y ago
        Yup. It is possible that your service is buffering output before actually writing it to the standard error stream. Try attaching to it with strace -e write PID and observe whether it is actually calling write(2, "some message"..., somenumberofbytes). To approach this from the other direction, try this program: import sys, time while True: print('test out', flush=True) print('test error', file=sys.stderr, flush=True) time.sleep(5) With this service: [Service] Type=simple ExecStart=/usr/bin/python3 /tmp/test.py
_ZeD_ 10y ago
(from tfa): "Now, let us turn our attention to the benefits that systemd brings us. I believe that these are the reasons that all Linux distributions have adopted systemd." ahem slackware has not adopted systemd
- yjftsjthsd-h 10y ago
  Nor has Gentoo adopted it as the primary system (and, in fact, OpenRC remains a favorite alternative).
deleted 10y ago
[deleted]
throw2016 10y ago
Systemd has a lot of attention and people working on it and it will eventually become good enough for the vast majority. But there were questionable tie-ins with various pieces like udev, consolekit and even gnome that allowed Systemd to become defacto init. The call for a kernel bus promotes a similar lock in with Systemd and this makes the use or development of alternatives and choice difficult. There are things like predictable network names which are useful for 1% of users and are anything but predictable. Binary logging makes sense for the security industry Redhat serves but again has no use for the 99% others who anyway have to put up with it. There is a pattern of forcing things onto everyone that make sense for a tiny minority. The big problem is open source funding. No one is interested in just supporting projects they benefit from. Acquisitions or hiring developers put these projects and developers under the control of companies like Redhat. Redhat has become a cathedral and a cathedral by sheer size and nature is always interested in securing and furthering its own influence and interests. When you allow such forces to become too powerful they will subsume the public interest to their interest.
msimpson 10y ago
Personally, I love Systemd for Web development as it makes the job of managing Node.js projects a breeze. I simply pack a Systemd unit file into a project's repository as part of its multi-environment configuration and construct deployment tasks to copy, enable, then start the unit file. 1. Copy <unit.service> to the sever, which looks like: [Unit] Description=<name> Service After=network.target [Service] Restart=always StandardOutput=syslog StandardError=syslog SyslogIdentifier=node-<name> User=<user> Group=<group> WorkingDirectory=/srv/node/<name>/current/ Environment="NODE_ENV=production" Environment="PORT=2580" ExecStart=/usr/bin/node server.js [Install] WantedBy=multi-user.target 2. Enable the unit file in place: sudo systemctl enable /srv/node/<name>/config/<unit.service> 3. Start the unit file: sudo systemctl start <unit.service> And, of course, destroying that deployment is just as easy.
Sembiance 10y ago
Who can I donate money to that is a competitor to systemd? I already donate to Gentoo (OpenRC) but was wondering what else I can donate to in order to fight the systemd plague.
kasabali 10y ago
Yet another systemd post which - Handwaves real criticisms and instead tries to look like an objective writing by presenting a trivial issue - Have no idea about advances in sysvinit in the last decade that allowed support for parallel boot and dependency relations (and which was supported natively on mainstream distribution) - Totally ignores the other "modern" and widely used init system and instead compares systemd with sysvinit of 80's (which wasn't used by any mainstream distro in that form) - Overrates process supervision features which were already as equally as easy to use with supervision suites like runit (IMHO even easier) Meh, what did I expect? Bandwagon is going full speed.

208 points by naftulikay 10y ago

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 ago
As 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 ago
  Bash 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 ago
    And 90% of that 90% has that tiny modification that is a nightmare to debug.
    - jstimpfle 10y ago
      What he wanted to say: you can debug since context is very local. (not taking sides)
    - lisivka 10y ago
      Use `set -x` or `bash -x script.sh` to trace shell script execution. Shell scripts are easy to debug.
      - eropple 10y ago
        I 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 ago
    You 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 ago
      Yep, they are. Shell is lingua franca for system administrators for whole history of UNIX.
      - rodgerd 10y ago
        Which 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 ago
        What 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 ago
    I 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.
    - ktRolster 10y ago
      There's this example for your approval: https://news.ycombinator.com/item?id=13388322 https://news.ycombinator.com/item?id=13388322
      - emmelaich 10y ago
        The reply from bazurbat covered it well.
- pmahoney 10y ago
  Many 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 ago
    Binary logs, hex logs, there's enough stupidity to go around!
- problems 10y ago
  What 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 ago
  Watch the special case directives grow until you can use systemd to implement Conway's Game of Life...
aaronky 10y ago
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.
- jcrites 10y ago
  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 <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 ago
http://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 ago
Poettering 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'

pkaye 10y ago

One of the things I like about systemd is you can get a graph of the boot time along with critical path via the following: systemd-analyze plot >boot.svg

awinder 10y ago

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.

nictrix 10y ago
I agree, Upstart was great for most things and was simple to understand. Though I ran into some difficult fork, exec issues for certain processes. I sometimes had to run a wrapper to use upstart, but those seemed to be edge cases. I'd prefer if we stuck with Upstart and improved on it, though it already seems like a distant dream.
- digi_owl 10y ago
  I sometimes wonder if edge cases are inherently fractal. take care of one and two more spawn. Thus when i see some dev talk about exorcising edge cases because of user friendliness i see them preaching a fools errand.

Karrot_Kream 10y ago

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.

djsumdog 10y ago
I don't feel they should. These are arguments I haven't heard before either and I'm glad to see more of these weird cases laid out. I run Gentoo (OpenRC) and Void (Runit) on my own systems, and although I do like both of them, I find the total lack of alternatives to the systemd ecosystem troubling. As a package maintainer, I do like being able to create rpms/deb files and only needing one standardized init script, so there is are a few advantages to systemd, but not many. It's complexity makes it difficult to create drop in replacements (work has stopped on uselessd and others). There needs to be more community support for distros like Void and real alternatives. Articles like this encourage that kind of thinking.
- lisivka 10y ago
  Why not to write generator of init scripts from Systemd unit files? Unit files are well documented for typical options and are easy to write.
  - JdeBP 10y ago
    Ahem! * http://jdebp.eu./Softwares/nosh/worked-example.html http://jdebp.eu./Softwares/nosh/worked-example.html * http://unix.stackexchange.com/a/200281/5132 http://unix.stackexchange.com/a/200281/5132 * https://www.mail-archive.com/supervision@list.skarnet.org/msg01227.html https://www.mail-archive.com/supervision@list.skarnet.org/ms...
- microcolonel 10y ago
  Where systemd is complex, it's because the use case is complex. If you know so much about these use cases, and you think systemd is unnecessarily complex, why don't you do it yourself and see where that takes you?

deleted 10y ago

[deleted]

FeepingCreature 10y ago

I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency handling. https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.gentoo.org/wiki/Comparison_of_init_systems > OpenRC provides a number of features touted as innovative by recent init systems like systemd ...

ashark 10y ago
OpenRC's the only init system I've actually liked. It's one of the things I really miss from when I used Gentoo, and I don't know why more distros didn't adopt it years ago.
- ausjke 10y ago
  probably it is not related to technical, SystemD has Redhat in the back initially I think.
- dijit 10y ago
  You should check out SMF, if you have a couple of hours to play with Solaris.. it handles things that systemd does (socket activation, process management/watching etc;) but in an orthogonal way that makes sense. I like openrc, I also like runit (for different reasons) but SMF is the gold standard for me and I recommend more people check it out. Even if it has XML elements :(
- JdeBP 10y ago
  TrueOS has just switched from Mewburn rc to OpenRC. They've had some problems to overcome.
- johnny22 10y ago
  OpenRC was definitely my favorite init system before systemd existed. Definitely beat out the defaults of distributions who were using the debian/redhat style sysvinit.
edoceo 10y ago
I'm on Gentoo and remember the switch to OpenRC. I was nervous. But all the old stuff worked! And my custom init scripts? Changed only one or two lines to make them work and a few more edits to make them fully OpenRC like. Backwards compatible FTW! And, now with OpenRC it still "just works". Fast, predictable boot with logs in normal places that I can easily debug, manage and modify.

colemickens 10y ago

Why would you run the Exec command through systemd-escape? The help text says that's for the NAME of the unit... Am I missing something? Also, I'm failing to think of a scripting purpose that requires you to place non-trivial bash directly in a systemd unit that couldn't be solved by writing out the script somewhere and just invoking the script in the unit.

chungy 10y ago
> Am I missing something? You're not. Contrived example is contrived.
naftulikay 10y ago
> Now agreed, if your workflow demands that you embed a Bash while loop in a unit, you’re already in a bad place, but there are times where this is required for templating purposes. It's right there in the post. I have indeed had to do something like this in the wild to run a Docker container with special needs.
- admsyn 10y ago
  Both you and OP haven't mentioned why you needed to do it inline as opposed to in an external script, though.
- colemickens 10y ago
  I don't see how "templating purposes" answers the question. I deploy services on VMs that need to parameterized and I can parameterize via templating a written-to-disk shell script that is then just simply executed in the unit... or I can have more dynamic parameterization and use environment variables and Environment= lines in the unit. The latter solution means the substitution is effectively happening in the same place as if they were inlined parameters, so I can't imagine a scenario when it wouldn't be workable.

agumonkey 10y ago

Systemd ideas I'm all for but it only hints at linux lack of clean abstraction power. sysvinit was full of redundancy; apparently BSD found a way to make a thin abstraction layer to make init files clean. Bash isn't "good" at hinting proper abstractions, I rarely see talks about this, maybe gurus can see through the rain. I keep seeing a place for a tiny lambda friendly intermediate layer .. Just so you can compose properties of your services like clojure ring middleware. (-> (path "/usr/bin/some-service" "arg0" ...) (wrap :pre (lambda () ...) :post (lambda () ..)) (retry 5) ... (timeout 5)) Is this ugly to your eyes ? ps: the idea is that (retry 5) is a normal language function, and not a systemd opaque built-in, you can write your own thing, and the most used can go upstream. Hoping to avoid the sysvinit fragility and redundancy.

djsumdog 10y ago
Have you looked at the runit init system? Here is /etc/sv/sshd/run on void linux: #!/bin/sh ssh-keygen -A >/dev/null 2>&1 # Will generate host keys if they don't already exist [ -r conf ] && . ./conf exec /usr/bin/sshd -D $OPTS Service scripts are dead simple on Void.
- agumonkey 10y ago
  Where do you specify laziness, failure policy etc ?
  - hedora 10y ago
    Why would I specify those in an init script? openssh has been doing The Right Thing(TM) for about two decades. Also, openssh has protocol-specific (and secure by default) configuration options around connection lifecycle, etc. that no general purpose init system should try to replicate and then blindly apply to unrelated services.
    - geofft 10y ago
      OpenSSH is the unusual case. Most the the services I run don't do the right thing. That's why, for instance, Debian wrote the start-stop-daemon utility years before anyone ever dreamed of systemd. I've been greatly enjoying systemd for the ability to write services and startup jobs in languages that don't have great libraries for doing all the right things, like Python and shell, because it gives me all those Right Things as effectively a library. I don't have to manage pid file handling and daemonization and restarts on my own; systemd will do it, and will do it well and Right. (I used to do this with start-stop-daemon, and it did it poorly and only okay.) It will also get out of the way of OpenSSH, which does it well and Right, and get in the way of the dozens of services that think they're doing it well and Right but aren't. Easy things should be easy, and hard things should be possible. systemd supports both. If that's the extent of what runit can in fact do, it only supports the former. (SysV-style init, of course, just makes easy things hard and hard things confusing, but as everyone else is saying, it's very not the standard of comparison here.)

baybal2 10y ago

Systemd is an init written by a terminal stage architectural astronaut

CaptSpify 10y ago

I'll put my opinion in the middle ground with systemd as well. I like a lot about it, and I dislike a lot about it. I really think the best thing they could have done would have been to make it modular. If people could just turn off the "features" that they don't want, there wouldn't be so much bitching about it. Instead they keep trying to shove everything into one giant pile, and don't understand why people get upset.

srslack 10y ago
You'll find that there's pretty much nothing you can't outright disable, except for journald. journald needs to be running, but you can turn off the binary logging and redirect everything to syslog. systemd itself is a collection of system daemons, as well as small programs to interact with those daemons, and almost all of them are disabled by default. That's my experience on Arch, and they adhere strictly to upstream defaults. If that weren't enough you could simply leave out the daemons you don't like at compile time.
- JdeBP 10y ago
  > you can turn off the binary logging Every time that people write that they tell other people who do know systemd that they do not know it. The journal cannot be turned off. Making it be stored in files in /run/log/journal/ instead of in files in /var/log/journal/ is not turning it off. It's making it non-persistent so that it doesn't last across system restarts, delegating the job of writing persistent logs to post-processing services that (nowadays) read the journal using its systemd-specific database access facilities. Ironically, making it not be stored in any files at all would actually prohibit the post-processing services from working, as they would have nothing to read and to process into their own formats. * http://unix.stackexchange.com/a/332315/5132 http://unix.stackexchange.com/a/332315/5132
  - srslack 10y ago
    >they tell other people who do know systemd that they do not know it. I appreciate the concern, thanks. >The journal cannot be turned off. The persistent binary logging is turned off, which is what people bitch about. Obviously, many of systemd's monitoring features are tied to the journal, and as stated journald still needs to be running, obviously writing to a non-persistent journal for these and forwarding logs (if specified.) >delegating the job of writing persistent logs to post-processing services that (nowadays) read the journal using its systemd-specific database access facilities. It's true that syslog-ng pulls messages from the journal, whereas syslog implementations that are not aware are provided with them over a compatibility socket, but this is a performance optimization, to reduce system overhead. Not really an important distinction. The context was turning persistent logs off and switching to on-disk and persistent text logs with syslog. If you really wanted to nitpick: dbus and udev are totally non-optional.

Sir_Cmpwn 10y ago

I've found runit to be the best (but not perfect) as far as init systems go. Check it out.

weberc2 10y ago

> Admittedly, it requires an environment file I know almost nothing about systemd, but you can define environment variables inline instead of in a file: `Environment=ENV_VAR=value`.

ausjke 10y ago

The sad thing is, you do not really have a second option, yes I know some distros say they have alternatives, but SystemD becomes the "preferred" init system nearly everywhere now. I just hope Debian to get rid of SystemD and return to whatever else. I know I'm biased, just failed to find a reason to love SystemD, tried a few times.

hedora 10y ago
I've found that devuan is a joy to use on my laptop. I'm also rotating BSDs and open source solaris variants on to the home network machines. (Switching to solaris to get rid of systemd would be overkill; I switched to joyent triton for better containers and zfs...)
- ausjke 10y ago
  Devuan has jessie in beta now, at the moment I have not given up on linux yet, am going to try Devuan.

alyandon 10y ago

At first I didn't care much for the idea of having to learn yet another init system but as I had to write ansible automation stuff for services on Centos 7 it was kind of required that I have some basic understanding of systemd. I have to say now that I'm more familiar with it it has begun to grow on me. There is something subjectively nice to me about running systemctl status and seeing a nice, clear picture of what the current state of services are on a system, being able to control the life cycle of a service including having systemd monitor and restart it, not having to deal with improperly written init scripts, etc. Stockholm Syndrome perhaps?

jcrites 10y ago
Russ Allbery's investigation [1] into alternative init systems, in the Debian's project to select the best one, also viewed this systemd property in a similar way -- a surprising and unexpected benefit. Systemd's native understanding of cgroups, process hierarchy, and logging makes this view possible. [1] https://news.ycombinator.com/item?id=13387989 https://news.ycombinator.com/item?id=13387989
astrodust 10y ago
The idea of systemd isn't bad. What's annoying is the friction involved in using it. It's just a shade too ornate, a little too magical, in both cases only by a small degree, but it's an important one. Creating a workable systemd init script is actually pleasant. Getting it running is easy. Checking for errors with status is nice, but searching the logs is annoying. pm2 (https://github.com/Unitech/pm2 https://github.com/Unitech/pm2) has a neat feature where you can watch logs easily, someting that systemd should totally steal and pack into journalctl, like "systemctl logs sshd" shows it in real-time, an alias to the obnoxiously verbose "journalctl -u sshd -f"
- nvarsj 10y ago
  I'm not sure how you could write this with a straight face. Systemd has friction, but writing init scripts doesn't? Are you kidding me? Have you ever had to write init scripts for production servers? Writing systemd unit files is entirely more straightforward and simple than any init script hackery. And how is "journalctl -u sshd -f" not straightforward? Systemd has its issues sure, but your comment is pure FUD.

peterwwillis 10y ago

The problem with systemd is not that it is "bad". There's a lot worse software out there. Systemd is relatively competently programmed. And it's even useful! The problem with systemd has always been that it forces you to do everything the systemd way, and usually to use its tools. It goes against everything that has helped GNU/Linux become a great system: that it wasn't really one system. It was bits and pieces, and you could add them together however you wanted to get something you liked. Systemd is the opposite. It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. I can compare it to Windows, but I feel like that would be an insult to Windows' usability. If this one single fact was different, everyone would love systemd, because it has plenty of useful features. But because it is designed specifically to please a single quirky user, people hate it.

jcrites 10y ago
> It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. Could you share a few specific examples? That hasn't been the case at all for me. I have worked with systemd and have had the opposite experience. I simply write textual config files describing how to launch the service, which can be done in a variety of ways. Could you share more about how you tried to use systemd? I'd encourage you to read Russ Allbery's analysis of systemd [2], which includes a description of his experience converting one of his packages to use systemd. He remarks on the well-done integration and its compatibility: * 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 think Russ's passage exhibits the opposite sentiment from the one you wrote. Russ says you can get the benefits of systemctl and journalctl if you want, but you can also use syslog in the old-fashioned way if you want. This has been my experience with systemd as well. I still have a habit of writing "service postfix restart", which still works but is not the systemd-idiomatic way. I don't even have the "correct" way memorized because the old way that I'm used to using works. So what I'm asking is, have you tried to achieve something with systemd and found that you were forced to do it differently? I'd be curious to learn more about what those cases were. I'm not affiliated with systemd project, but I have a general interest in wanting to see it improve. (Please note that, barring conventions of some kind that span multiple tools, every tool naturally requires you to do things that tool's own way. If you are holding systemd to the standard that its job should be able to be performed by two different tools, each with the same interface, while supporting advanced features, then you should have other examples of this as well.) [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... [2] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html

secabeen 10y ago

I've never particularly liked init systems that restart jobs when they die. Normally, I don't want daemons that crash to restart. They should die, be caught by monitoring and the server bypassed. I would accept a single restart but after that, there's clearly a problem, and the systems should fail, rather than restarting the process again and again and again.

plorg 10y ago
As a single user with a number of personal/hobbyist machines, I actually find systemd annoying to work with for precisely this reason. If a daemon is misconfigured and fails to launch several times in a row, it inevitably triggers the systemd "too many retries" error, after which systemd will refuse to start the daemon until some timeout has expired or the counter is cleared. This makes troubleshooting more difficult and frustrating.
- kinghajj 10y ago
  Funnily enough, just dealt with a bug caused by this at work. The small PC would boot before the cellular modem had an Internet connection. Services that communicate via MQTT would immediately attempt to reach the broker, and throw an exception. My quick fix was just to add "RestartSec=5" so that the faulted state would never be entered.
  - kasabali 10y ago
    Ironic considering how systemd developers brag about eliminating race conditions and sleep calls from init scripts.

digi_owl 10y ago

More and more systemd is becoming symptomatic of deeper divide within the Linux "community". The split being between those that embraced Linux for being a free, in both senses, _nix unburdened by AT&T and running on commodity hardware, and those that got to know it after the dot-com crash as the L in LAMP. The former cares for Linux as a _nix, the latter could not care less about _nix and may see it as a vestigial appendage that should have been amputated long ago.

AnonymousPlanet 10y ago
I'm not so sure if it really has that much to do with heritage. A lot of us like the design principles you can see in Unix and that are pretty much absent in systems like Windows NT. They very much reflect the conclusions I came to after over fifteen years of building and debugging systems. But, yes, I have the impression that a lot of Linux users would just as gladly use a modern BeOS or a ReactOS, regardless of the underlying design. And a lot of systemd criticism comes from people who are just averse to any kind of change and maybe long for the bygone days of HP-UX and Irix.
- digi_owl 10y ago
  There is change and there is change.
vidarh 10y ago
No, it's symptomatic of most of the Linux community having embraced systemd, and the holdouts being few and far between.
teddyh 10y ago
Let me just say that I disagree: I am squarely in the former camp – I started with SunOS 4 in 1992, learned to use the Internet before the WWW, and am a long-time GNU advocate, and I am also a professional system administrator. I like systemd just fine. In fact, I started using it at home and at work just as soon as the package became available in Debian 7 (wheezy). I think, however, that you have a point in that some people ascribe some mystical properties to the design of _nix and _nix-like systems. I have never done this, perhaps because I remember the early days of OS/platform wars (Amiga or Atari? PC or console? Unix or VMS?), first on BBSes, then on Usenet. I also, early on, read the Unix-Haters Handbook, and I found it enlightening, even though it is not always spot-on. I leave all die-hard advocates with this quote: “All Software Sucks, All Hardware Sucks” (http://www.absurdnotions.org/an20010622.gif http://www.absurdnotions.org/an20010622.gif) (Source: (http://www.absurdnotions.org/page75.html http://www.absurdnotions.org/page75.html). Start of storyline: (http://www.absurdnotions.org/page74.html) http://www.absurdnotions.org/page74.html))

sebcat 10y ago

> The justification for storing logs in a binary format was speed and performance, they are more easily indexed and faster to search. Are there any benchmarks for this? I don't know why, and I may be doing things wrong, but journalctl -lu <unit> --since yesterday in our prod env takes a couple of seconds before I see any output, while a (z)grep on a date rotated, potentially compressed log file on a non-journald system is generally instantaneous. On a side note, I really like machine parsable, human readable logs, and I've never had any speed or performance issues with it when dealing with volumes of hundreds of millions of log entries, though that may be because I don't know any better.

flukus 10y ago
My question would be "is searching worth optimizing for anyway?". Log files are typically only read when things go wrong or by automated systems where a few seconds here or there doesn't make much of a difference. Faster to search often means slower to write too, I'd prefer faster to write and slower to search if I had to choose.
gens 10y ago
Of course nobody benchmarked. Rarely are there programmers in OSS these days that benchmark anything. (not nearly as common as those who claim "speed") There was a bug though where the journaling was so slow it caused the whole server to crash. (sorry, can't find it right now; something about them using mmaped files and the access pattern was.. or something, interesting stuff:) Binary logs should be faster, in theory, and should/could be as robust as text logs (if not more), in theory. edit: note that GNU grep is insanely optimized.
- pif 10y ago
  > Rarely are there programmers in OSS these days that benchmark anything. Please, don't release such a bold statement without any source. Please!
  - yjftsjthsd-h 10y ago
    How would you cite the lack of testing? GP did discuss several regressions that imply performance wasn't thoroughly tested.

krylon 10y ago

At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it's problematic that it is so Linux-centric and will cause problems maintaining software to run both on Linux/systemd and on *BSD. The way it was pushed on distros was problematic, in my opinion. But having used a couple of Linux systems running systemd - Raspian Jessie and openSUSE - I have to admit it's not that bad. In practice - on laptops and desktop systems (assuming one counts the Pi as a desktop system; for my use case, I do) - I had no problems with it. Enabling and disabling services is a lot easier. I do not think is as great as its proponents claim, but it's not as bad as some people think, either. Personally, I have come to appreciate journald, even though I still agree that binary logs are a bad idea. At least there is still the option of installing a syslog daemon.

digi_owl 10y ago
Some parts may be useful, some parts are downright awful, but the clincher is that it is all a big wadded up ball of code. Damn it, the LFS team basically adopted eudev, of Gentoo fame, because extracting udev from systemd required manual intervention over and over.
- noinsight 10y ago
  > a big wadded up ball of code. To be clear, they're all under the same umbrella project, but separate components and not everything is in PID 1. People seem to be confused by that.
  - digi_owl 10y ago
    Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.
    - krylon 10y ago
      OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.

svennek 10y ago

Most people I hear having problems with Systems is either on Redhat or Debian - not realising the both are mangling systemd badly. RHEL took in systemd way too early and are missing a lot of needed functionality. Also the have an ungodly amount of patches on top - so much you could argue it should be named redhatd instead. Debian just chooses to take the worst possible middle position due to politics. All of the disadvantages from systemd, but not really any of the great stuff as systemd units often just start shellscripts due to compatibility.... If you want to try systemd in all its glory try Arch or something downstream from it... I for one think that systemd has made my admin-life so much better ..

AstralStorm 10y ago
I am running systemd on Gentoo. (like Sabayon) While some of the features are nice, it is a royal pain to upgrade due to intertwined deps and forced restarts. And it doesn't do anything OpenRC couldn't do, in fact its journald is a pain which had to be worked around. OpenRC way of doing socket activations and dbus activations also works slightly better (in case something crashes) It does parallelism just as well, service dependencies too. Gentoo does not mangle anything related to systemd unlike the mentioned distributions.
- svennek 10y ago
  Yeah, Gentoo is quite nice in that regard, but isn't it still focussed on openrc? I was a ten plus years gentooo user before I switched to Arch (mostly because I got fed up with compiling)
  - jakeogh 10y ago
    OpenRC is the first option in the install guide, but you can choose systemd. I cant think of a good reason to do so.

nvarsj 10y ago

I get the feeling anyone who complains about systemd is just a hobbyist jumping on a hate bandwagon. For anyone who manages production systems, systemd is a godsend compared to the homegrown-per-distro shell based init systems.

msimpson 10y ago
Did you actually read the article or just these comments?

tannhaeuser 10y ago

Best thing of systemd is that it's putting people behind alternate systemd-free Linuxen. Devuan, Alpine, Gentoo, Void (and particularly the BSDs) come along nicely. I can tolerate systemd on desktops as long as I don't have to deal with it. The moment it craps out with Java-esque error traces in binary logs I'll install Slackware (or is there a modern desktop Linux without systemd I'm not aware of?). Other than for desktops with complex run-time dependencies (WLAN, USB devices, login sessions), what are the benefits of systemd for servers that warrant a massive, polarizing, tasteless monolith which puts you up for endless patches and reboots, especially in a container world? (Re-)starting and stopping a daemon isn't rocket science; it's like 10 lines of shell code.

dijit 10y ago
SystemD was so polarizing for me, I was a Fedora user and RHEL user for work- but it started consuming everything and giving really bizarre issues... I tried reaching out and explaining to people that it wasn't working in the way I expected or, asking them to point me towards the docs so I can at least learn how to use journalling properly so it doesn't hide issues from me.. and was met with some hostility. When I asked to disable binary logging entirely because it kept getting corrupted and was opaque I was met with "Unlearn your old ways old man"-style responses and "You can just log to rsyslog too".. No, I want it disabled.. I don't have a desire to log twice.. It was then I realised I was at the mercy of systemd, they can push whatever and reject whatever and I'm completely out of control- I cannot introspect their service manager effectively, it's non-deterministic. It just reeks of hubris from the maintainers. It does mostly the right thing for most people, and they compare it to sysvinit which admittedly needed love. (and, was not a process manager, was only a process starter). So, I adopted *BSD on the server. And christ is it wonderful. I still use Arch/SystemD on my desktop at home, because it's actually pretty useful on laptops/desktops. But I swore a vow never to manage a server with SystemD on it. I'm still runing RHEL6 at work, for the next OS, I'm pushing my very large corp to adopt FreeBSD as an alternative. That's a fairly large amount of money that Red Hat will lose and I don't particularly feel bad about it. They forced my hand.
- tannhaeuser 10y ago

nailer 10y ago

Does systemd have a network protocol like syslog, i.e. is there a native way to send logs for a particular unit/service to a remote machine? Everything I find just says to install syslog, which surprises me.

JdeBP 10y ago
Would native actually be your preference, though? Or would you really prefer tools that spoke existing protocols like RELP?
- nailer 10y ago
  native would be my preference as I'd rather avoid installing any software at all. Protocol will be HTTPS, format will be https://www.freedesktop.org/wiki/Software/systemd/json/ https://www.freedesktop.org/wiki/Software/systemd/json/
nailer 10y ago
Actually found what I was looking for (via http://stackoverflow.com/questions/23082512/coreos-systemd-journal-remote-logging http://stackoverflow.com/questions/23082512/coreos-systemd-j...): https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html https://www.freedesktop.org/software/systemd/man/systemd-jou...

z3t4 10y ago

My main complain about systemd is that it does not log the stderr stream !!

yrro 10y ago
It does log the standard error stream. The default value of StandardError= is inherit, which will cause stderr to go to the same place that stdout goes, which by defaults to journal. This is documented in systemd.exec(5). If not overriden in an individual service's unit file, perhaps you have set DefaultStandardError= in /etc/systemd/system.conf?
- z3t4 10y ago
  The problem is that it doesn't store "unit" meta-data for stderr, so you can not see stderr logs with journalctl -u nameOfUnit or systemctl status nameOfUnit
  - yrro 10y ago
    I do not find this to be the case. Right now I'm looking at the journal and observing the existence of _SYSTEMD_UNIT fields for messages that have been written to a process's standard error stream.
    - z3t4 10y ago
      Can you see them when you run journalctl -u nameOfUnit or systemctl status nameOfUnit ? I'm running Ubuntu server.
      - yrro 10y ago
        Yup. It is possible that your service is buffering output before actually writing it to the standard error stream. Try attaching to it with strace -e write PID and observe whether it is actually calling write(2, "some message"..., somenumberofbytes). To approach this from the other direction, try this program: import sys, time while True: print('test out', flush=True) print('test error', file=sys.stderr, flush=True) time.sleep(5) With this service: [Service] Type=simple ExecStart=/usr/bin/python3 /tmp/test.py

_ZeD_ 10y ago

(from tfa): "Now, let us turn our attention to the benefits that systemd brings us. I believe that these are the reasons that all Linux distributions have adopted systemd." ahem slackware has not adopted systemd

yjftsjthsd-h 10y ago
Nor has Gentoo adopted it as the primary system (and, in fact, OpenRC remains a favorite alternative).

deleted 10y ago

[deleted]

throw2016 10y ago

Systemd has a lot of attention and people working on it and it will eventually become good enough for the vast majority. But there were questionable tie-ins with various pieces like udev, consolekit and even gnome that allowed Systemd to become defacto init. The call for a kernel bus promotes a similar lock in with Systemd and this makes the use or development of alternatives and choice difficult. There are things like predictable network names which are useful for 1% of users and are anything but predictable. Binary logging makes sense for the security industry Redhat serves but again has no use for the 99% others who anyway have to put up with it. There is a pattern of forcing things onto everyone that make sense for a tiny minority. The big problem is open source funding. No one is interested in just supporting projects they benefit from. Acquisitions or hiring developers put these projects and developers under the control of companies like Redhat. Redhat has become a cathedral and a cathedral by sheer size and nature is always interested in securing and furthering its own influence and interests. When you allow such forces to become too powerful they will subsume the public interest to their interest.

msimpson 10y ago

Personally, I love Systemd for Web development as it makes the job of managing Node.js projects a breeze. I simply pack a Systemd unit file into a project's repository as part of its multi-environment configuration and construct deployment tasks to copy, enable, then start the unit file. 1. Copy <unit.service> to the sever, which looks like: [Unit] Description=<name> Service After=network.target [Service] Restart=always StandardOutput=syslog StandardError=syslog SyslogIdentifier=node-<name> User=<user> Group=<group> WorkingDirectory=/srv/node/<name>/current/ Environment="NODE_ENV=production" Environment="PORT=2580" ExecStart=/usr/bin/node server.js [Install] WantedBy=multi-user.target 2. Enable the unit file in place: sudo systemctl enable /srv/node/<name>/config/<unit.service> 3. Start the unit file: sudo systemctl start <unit.service> And, of course, destroying that deployment is just as easy.

Sembiance 10y ago

Who can I donate money to that is a competitor to systemd? I already donate to Gentoo (OpenRC) but was wondering what else I can donate to in order to fight the systemd plague.

kasabali 10y ago

Yet another systemd post which - Handwaves real criticisms and instead tries to look like an objective writing by presenting a trivial issue - Have no idea about advances in sysvinit in the last decade that allowed support for parallel boot and dependency relations (and which was supported natively on mainstream distribution) - Totally ignores the other "modern" and widely used init system and instead compares systemd with sysvinit of 80's (which wasn't used by any mainstream distro in that form) - Overrates process supervision features which were already as equally as easy to use with supervision suites like runit (IMHO even easier) Meh, what did I expect? Bandwagon is going full speed.