7 ms·

> I wouldn't be against systemd if it were just an init system. The problem is that it's not. That's the end of my argument. All of systemd's functionality, as

> I wouldn't be against systemd if it were just an init system. The problem is that it's not. That's the end of my argument. All of systemd's functionality, as far as I'm concerned, is rationally motivated by wanting to orchestrate and instrument system startup in a sensible way. What functionality do you think systemd should not have that it has today? What is a better way of achieving the result provided by that functionality? If your perspective is that you don't care about that functionality or the related user experience, and so all of its complexity is dead weight to you, OK. That makes sense. But as a software engineer and system administrator, I find the features extremely useful, and I think many other people do too. That's why systemd has been adopted by major distributions. I wrote a comment earlier [1] about systemd that reviews Russ Allbery's analysis of systemd [2], from when Debian was evaluating switching to systemd and upstart. Russ's comment reviews a number of different systemd functions, such as its integrated journal, and then explains the pros and cons of each. Russ even said: 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. [lots more details in linked comment] [1] https://news.ycombinator.com/item?id=13387989 https://news.ycombinator.com/item?id=13387989 [2] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html Sure, you could argue an init system "shouldn't" have an integrated journal (for example), but then you'd lose the clear benefits that Russ outlines. You wouldn't achieve the same benefits or user experience. Similarly, systemd's configuration-driven approach to service definition makes it possible to employ a wide variety of standard configuration options across all services. From my previous comment: > 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.

dozzie 9y ago
> All of systemd's functionality, as far as I'm concerned, is rationally motivated by wanting to orchestrate and instrument system startup in a sensible way. What functionality do you think systemd should not have that it has today? QR code generator? Message broker (IPC)? Underdeveloped, brittle, and overcomplicated syslog replacement? Task scheduler?
- jcrites 9y ago
  > Underdeveloped, brittle, and overcomplicated syslog replacement? Are you referring to the systemd journal? I think you should lay out your arguments in detail if you want to make claims like that, since there is a lot of compelling evidence to the contrary. Russ Allbery's analysis of systemd [1] lays out a convincing case that the journal is a highly developed, flexible, and useful feature: * 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. [...] 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. [1] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html The benefits that Russ describes above are meaningful, tangible improvements to the user experience that helps system administrators like me. Far from being brittle, the journal seems quite flexible (being "agnostic to the underlying syslog implementation"); it seems highly-developed and well-integrated into the systemd toolkit, and I see no evidence that it's over-complicated. > Message broker (IPC)? Are you referring to dbus? Dbus is not part of systemd and predates systemd by almost a decade! Dbus already had significant adoption when systemd took a dependency on it. It's used by GNOME, KDE, and even the Upstart init system. From Lennart Poettering's blog [2]: D-Bus has been a core component of Linux systems since more than 10 years. It is certainly the most widely established high-level local IPC system on Linux. Since systemd's inception it has been the IPC system it exposes its interfaces on. And even before systemd, it was the IPC system Upstart used to expose its interfaces. It is used by GNOME, by KDE and by a variety of system components. [2] http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html

dozzie 9y ago

> All of systemd's functionality, as far as I'm concerned, is rationally motivated by wanting to orchestrate and instrument system startup in a sensible way. What functionality do you think systemd should not have that it has today? QR code generator? Message broker (IPC)? Underdeveloped, brittle, and overcomplicated syslog replacement? Task scheduler?

jcrites 9y ago
> Underdeveloped, brittle, and overcomplicated syslog replacement? Are you referring to the systemd journal? I think you should lay out your arguments in detail if you want to make claims like that, since there is a lot of compelling evidence to the contrary. Russ Allbery's analysis of systemd [1] lays out a convincing case that the journal is a highly developed, flexible, and useful feature: * 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. [...] 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. [1] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html The benefits that Russ describes above are meaningful, tangible improvements to the user experience that helps system administrators like me. Far from being brittle, the journal seems quite flexible (being "agnostic to the underlying syslog implementation"); it seems highly-developed and well-integrated into the systemd toolkit, and I see no evidence that it's over-complicated. > Message broker (IPC)? Are you referring to dbus? Dbus is not part of systemd and predates systemd by almost a decade! Dbus already had significant adoption when systemd took a dependency on it. It's used by GNOME, KDE, and even the Upstart init system. From Lennart Poettering's blog [2]: D-Bus has been a core component of Linux systems since more than 10 years. It is certainly the most widely established high-level local IPC system on Linux. Since systemd's inception it has been the IPC system it exposes its interfaces on. And even before systemd, it was the IPC system Upstart used to expose its interfaces. It is used by GNOME, by KDE and by a variety of system components. [2] http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html