Weblog entry #78 for dkg

The bleeding edge: systemd
Posted by dkg on Wed 27 Apr 2011 at 08:07

Curious about these shiny new things i keep hearing about, i set up a test desktop system using using systemd as the init system (yes, that means using systemd-sysv in place of sysvinit -- so i had to remove an essential package for this to work).

A system-crippling bug was naturally the result of living on the bleeding edge, but fortunately it was resolved with a trivial patch.

In all, i'm pretty happy with some of the things that systemd seems to get right. For example, native supervision of daemon processes, clean process states, elimination of initscript copy-paste-isms, and socket-based service initiation are all obvious, marked improvements over the existing sysvinit legacy cruft.

But i'm a bit concerned about other parts. For example, all the above-mentioned features fit really well within a tightly-tuned, well-managed server. But systemd also appears to rely heavily on complex userland systems like dbus and policykit that would be much more at home on a typical desktop machine. I've never seen a well-managed server installation that warranted either policykit or dbus. Also, given the bug i ran into -- when PID 1 aborts due to a silly assertion, your system is well-and-truly horked. Shouldn't a lot more attention to detail be happening? I'd think that a "recover gracefully from failed assertions" approach would be the first thing to target for a would-be PID 1.

I'm also concerned about the Linux-centricism of systemd. I understand that features like cgroups and reliance on the spiffiness of inotify are part of the appeal, but i also really don't want to see us stuck with only One Single Kernel as an option. The kFreeBSD folks (and the HURD folks) have done a lot of work to get us close to having some level of choice at this critical layer of infrastructure. It'd be good to see that possibility realized, to help us avoid the creeping monoculture. I worry that systemd's over-reliance on Linux-specific features is heading in the wrong direction.

So my question is: why is this all being presented as a package deal? I'd be pretty happy if i could get just the "server-side" features without incurring the dbus/policykit/etc bloat. I already run servers with runit as pid 1 -- they're lean and quite nice, but runit doesn't have systemd's socket-based initiation (or the level of heavyweight backing that systemd seems to have picked up, for that matter).

I understand that Lennart is resistant to UNIX's traditional "do one thing; do it well" philosophy. I can understand some of his reasoning, but i think he might be doing his work and his tools a disservice by taking it this far. Wouldn't systemd be better if it was clearer how to take advantage of parts of it without having to subscribe to the entire thing?

Of course, i might be missing some nice ways that systemd can be effectively tuned and pared down. But i've read his blog posts about systemd and i haven't seen how to get some of the nice features without the parts i don't want. I'd love to be pointed to some explanations that show me how i'm wrong :)


Comments on this Entry

Posted by Anonymous (50.43.xx.xx) on Wed 27 Apr 2011 at 08:52
Several of the features you care about, such as system supervision, depend heavily on mechanisms such as cgroups.

Who says that portability most remain limited to the POSIX API? How about extending the Linux compatibility of one of the BSD kernels to support cgroups, for instance?

[ Parent | Reply to this comment ]

Posted by jeremiah (194.237.xx.xx) on Wed 27 Apr 2011 at 09:49
[ View Weblogs ]
Interesting blog post.

I agree about the creeping monoculture. I also am a little skeptical about the non-UNIXy approach and its attendant complexity. Ubuntu might remain a hold out and not adopt systemd which makes things interesting, but overall I think this is a step in the right direction.

[ Parent | Reply to this comment ]

Posted by mcortese (20.142.xx.xx) on Wed 27 Apr 2011 at 09:54
[ View Weblogs ]

I think systemd:init = module.ko:compiled-in = udev:static /dev.

In a tightly tuned server you can compile all the needed modules into the kernel once and forever. Since your hardware will rarely change, a static /dev will be ok. And also, if your load will be more or less constant, probably you won't even need systemd.

On the other hand, for often-changing desktops the kernel never knows what hardare it will face at the next boot, or what kind of apps the user will ask it to run. In this case, udev, modules, systemd or dependency-based SystemV-like init scripts (see insserv), self-configuring X server, etc. are ways to be prepared for every condition. I'm not saying it is the right way, just that it's the current trend.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 27 Apr 2011 at 18:48
[ View dkg's Scratchpad | View Weblogs ]
Or, to raise a recent argument, it might be similar to the network-manager vs. ifupdown debate.

But the issue i'm raising isn't about being prepared for every condition -- i'm fine with systems that are prepared for every condition, and in particular, servers on the public network can't afford to think that their load will be "more or less constant", or that they will be subject to the same attacks that existed when they were first written. Good process supervision and isolation, tight permissions, and well-scoped roles can help a system maintain stability in the face of a changing network environment. systemd can be useful for all these things.

But polkit and dbus in particular don't seem to fit this bill. how does dbus or polkit make a system "more prepared for every condition"? It seems to me that they add to the complexity without giving a positive benefit for the server use case. (note that i'm not arguing against them for typical desktop machines -- they may well have a place there). Or am i misunderstanding dbus and policykit? I'd love to be corrected if i'm mistaken.

[ Parent | Reply to this comment ]

Posted by Anonymous (91.46.xx.xx) on Wed 27 Apr 2011 at 10:58
Nice article... systemd celebrated its 1st year anniversary.
It's not "bleeding edge" to me as I use it approx. for one year on Debain/sid.
Could you please refer to Debian's systemd wiki in your article?

- dileks -

[ Parent | Reply to this comment ]

Posted by Anonymous (77.4.xx.xx) on Wed 27 Apr 2011 at 12:27
I guess "bleeding edge" refers to experimental (since that bug doesn't exist in the unstable version).

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 27 Apr 2011 at 17:34
[ View dkg's Scratchpad | View Weblogs ]
I'm assuming you mean this wiki article. You are very welcome to put relevant links in the comments here too :)

I'm surprised you were able to run this on unstable -- i found that recent versions of udev conflicted with systemd < 25. Maybe you were just not upgrading udev or something?

[ Parent | Reply to this comment ]

Posted by Anonymous (78.53.xx.xx) on Wed 27 Apr 2011 at 21:12
systemd does not depend on policykit. Just wanted to correct this factual error.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 27 Apr 2011 at 21:29
[ View dkg's Scratchpad | View Weblogs ]
Hm, re-reading the rest of Lennart's series on systemd for admins (is there ever going to be an index for these other than the links on the systemd project page?), i think i agree with you -- policykit doesn't seem to be as heavily-emphasized as i remembered it being. Thanks for pointing that out.

The guide to writing password agents does seem to encourage policykit use. However, that might be a special case, perhaps more desktop-specific, and i'm sure there are ways to avoid needing policykit in a simple/well-tuned server.

Do you think it depends on dbus, though? Is there a good argument for doing that or is it bloat?

[ Parent | Reply to this comment ]

Posted by Anonymous (78.53.xx.xx) on Wed 27 Apr 2011 at 23:34
Strictly speaking, systemd only requires libdbus, which is used as internal IPC mechanism. It uses a private bus for this, which doesn't require a running dbus system bus. I think it makes sense that systemd does not re-invent its own IPC mechanisms. D-Bus is widespread and heavily tested.
FWIW, upstart uses D-Bus in a similar way. Originally it used its own IPC protocol (until version 0.3.x) which got ripped out and replaced by D-Bus.

If you want to use all features that systemd provides, you will want to start a D-Bus system bus though. Otherwise unprivileged processes can't talk to systemd and D-Bus system bus activation won't work

[ Parent | Reply to this comment ]