7 ms·

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.

by aaronky 10y ago

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
- hedora 10y ago
  Pid 1 runs its own DNS server now. It also launders kernel calls for non-setuid xorg (breaking rootless x on non-systemd boxes, since the kernel can't be bothered to consistently check process uid or gids, apparently). In turn, that means it must have some baroque authentication subsystem too. There is no way you need that in init. The amount of ancillary damage systemd causes far outweighs any possible benefits there are to improving init. Also, I have never seen a systemd box emit log lines like that for a failed service. It invariably points at some useless logfile with obscure systemd messages in it instead of the stderr of the failed process. This is on clean ubuntu and debian installs. Maybe it is user error, but I doubt it. (Though there is no command line in the examples...) Anyway, I'm happy to cleanse with fire instead of RTFM at this point. On a related note, I just learned the solaris init system and started using openbsd's again. I prefer them both to systemd. They are at opposite ends of a spectrum. The openbsd approach is well curated shell scripts. I think systemd was heavily inspired by the solaris thing.
  - viraptor 10y ago
    > Pid 1 runs its own DNS server now. It doesn't. Systemd has its own resolver (systemd-resolved), which has other issues, but it does not run in PID 1. It's a completely separate process. // I'm enjoying watching the points bouncing up and down, but if you disagree in some way, please comment :)
- flukus 10y ago
  I thought that was the part of systemd that was universally liked? The best arguments against systemd seem to be that everything becomes implemented in or tightly bound to it.
  - amyjess 10y ago
    This is also the rationale behind uselessd, which keeps the service management part and cuts out everything else.
- felixgallo 10y ago
xenadu02 10y ago
Who said the unit philosophy was the be-all, end-all? Unix doesn't even believe it's own philosophy because it's too damn painful. Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? Unix is just a collection of random decisions made by various people over the years. The Unix philosophy is really more like "I've always done it that way so don't you dare change it". fork/exec is garbage. Signals are garbage. You basically can't make any API calls after fork or in a signal handler because threads came after. The interaction of fork and threads is bananas and many hacks have been required over he years to paper over the problems. The layout of /usr/bin, /usr/sbin, /usr/local/bin, et al isn't a good design. It's dogshit but it was necessary because early Unix file systems couldn't span multiple volumes and early disk systems were small. The C compilation model of separate header files is not a good design. People have retroactively determined some of the side-effects are not only good but The One True Way. In reality the design was a result of extremely limited RAM and slow CPUs. The preprocessor itself was never designed, just grafted on ad-hoc. Unix file permissions are shit. Every unique combination of permissions requires a group. Owners are by simple integers. NFS legitimately gives people nightmares. Let's not even get into everything is a file, except when it's not, and some files are more equal than others. What about dependency hell? How's that "simple" model working out? The "Unix philosophy" can piss right off.
- jjnoakes 10y ago
  Most of this comment is incorrect.
  - skissane 10y ago
    I think xenadu02 raises some valid criticisms, but I think those criticisms would have been better received if they were expressed more politely. I'd love to see a rebuttal of the specific points made as opposed to just "Most of this comment is incorrect".
    - deleted 10y ago
      [deleted]
    - 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.

by 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

hedora 10y ago
Pid 1 runs its own DNS server now. It also launders kernel calls for non-setuid xorg (breaking rootless x on non-systemd boxes, since the kernel can't be bothered to consistently check process uid or gids, apparently). In turn, that means it must have some baroque authentication subsystem too. There is no way you need that in init. The amount of ancillary damage systemd causes far outweighs any possible benefits there are to improving init. Also, I have never seen a systemd box emit log lines like that for a failed service. It invariably points at some useless logfile with obscure systemd messages in it instead of the stderr of the failed process. This is on clean ubuntu and debian installs. Maybe it is user error, but I doubt it. (Though there is no command line in the examples...) Anyway, I'm happy to cleanse with fire instead of RTFM at this point. On a related note, I just learned the solaris init system and started using openbsd's again. I prefer them both to systemd. They are at opposite ends of a spectrum. The openbsd approach is well curated shell scripts. I think systemd was heavily inspired by the solaris thing.
- viraptor 10y ago
  > Pid 1 runs its own DNS server now. It doesn't. Systemd has its own resolver (systemd-resolved), which has other issues, but it does not run in PID 1. It's a completely separate process. // I'm enjoying watching the points bouncing up and down, but if you disagree in some way, please comment :)
flukus 10y ago
I thought that was the part of systemd that was universally liked? The best arguments against systemd seem to be that everything becomes implemented in or tightly bound to it.
- amyjess 10y ago
  This is also the rationale behind uselessd, which keeps the service management part and cuts out everything else.
felixgallo 10y ago

xenadu02 10y ago

Who said the unit philosophy was the be-all, end-all? Unix doesn't even believe it's own philosophy because it's too damn painful. Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? Unix is just a collection of random decisions made by various people over the years. The Unix philosophy is really more like "I've always done it that way so don't you dare change it". fork/exec is garbage. Signals are garbage. You basically can't make any API calls after fork or in a signal handler because threads came after. The interaction of fork and threads is bananas and many hacks have been required over he years to paper over the problems. The layout of /usr/bin, /usr/sbin, /usr/local/bin, et al isn't a good design. It's dogshit but it was necessary because early Unix file systems couldn't span multiple volumes and early disk systems were small. The C compilation model of separate header files is not a good design. People have retroactively determined some of the side-effects are not only good but The One True Way. In reality the design was a result of extremely limited RAM and slow CPUs. The preprocessor itself was never designed, just grafted on ad-hoc. Unix file permissions are shit. Every unique combination of permissions requires a group. Owners are by simple integers. NFS legitimately gives people nightmares. Let's not even get into everything is a file, except when it's not, and some files are more equal than others. What about dependency hell? How's that "simple" model working out? The "Unix philosophy" can piss right off.

jjnoakes 10y ago
Most of this comment is incorrect.
- skissane 10y ago
  I think xenadu02 raises some valid criticisms, but I think those criticisms would have been better received if they were expressed more politely. I'd love to see a rebuttal of the specific points made as opposed to just "Most of this comment is incorrect".
  - deleted 10y ago
    [deleted]
  - 10y ago