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 :)
[ Parent | Reply to this comment ]
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 ]
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 ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
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 ]
[ Parent | Reply to this comment ]
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 ]
[ Parent | Reply to this comment ]
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 ]