Jaeger: systemd - and #osc2010

Systemd does not rely solely on sockets for dependency. It also uses "file system" (service A only starts once directorory /foo/bar is available).

It solves a very real issue that Upstart and init scripts have. With those one needs either to have some other program that waits until e.g. X server socket or D-BUS socket is available, or modify X & D-BUS daemon to notify Upstart when they're ready, or use racy timeouts before continuing startup of processes depending on those daemons.

It's much nicer that the init program itself supports that kind of dep handling directly in a race-free manner.

After this you argument that there are many startup issues where socket based dependencies aren't enough and then you state that D-BUS can be used for them. So, what would be the point of starting those things directly from Systemd?

> So my question, how does systemd fit in, in a world where services have been converging on behaving more dynamically by keeping informed of changes in system state and reacting appropriately?

D-BUS cannot / isn't designed to act as system init, something needs to start that and those other things needed at bootup (X etc) which don't support D-BUS.

(Using D-BUS has also it's own downsides if it's used for everything. There are quite a lot of things in its implementation that need to be fixed, like its byzantine memory allocation code. All you need is one client that doesn't read its messages and eventually D-BUS daemon message buffer will take all the memory available in the system...)

Systemd fits in quite nicely there. Imagine that when DBUS service is activated, systemd captures this and starts a daemon, in its own process group (so it can be killed). Besides, it can track _who_ started the service and kill it when it's required.

As mentioned many times already, systemd's base is actually a dependency based system, on top of which we built the magic socket and bus activation logic. Criticising systemd for the "unexpressiveness" of socket activation goes in the completely wrong direction. In systemd the dependency logic was actually available first, and then we added the socket activation as an important building block on top, to reduce the complexities a strict dependency systemd passes to the admin. And sentences such as "That systemd had to quickly add support for manually configured dependencies..." are completely backwards and are completely misunderstanding what is going on with systemd.

Profile-based activation as you are asking for your location use case is actually trivially doable with systemd: simply create a target unit for each of your locations and hook the services you want to start into them. Then, you can easily switch between the different targets. (And if you wonder what a "target" is in this context, please refer to the docs).

Regarding your comments regarding D-Bus: note that D-Bus tightly integrates with systemd since version 1.3.1 so that we can do bus-based activation. (Oh, and as a matter of fact I am actually something like the maintainer of D-Bus these days -- at least I rolled the two most recent releases; I hope this makes clear that the work on d-bus and systemd is cooperative, not competitive) Solely focussing on bus-based activation is not sufficient to comprehensively cover what is needed for a modern OS. This is why systemd combines socket, bus, device, timer, path and boot based activation (and if you count the base of it all, the explicit dependencies in this context too also dependency-based activation), and then can handle them all in a unified fashion and without races. The latter is actually a much understated problem, since the big majority of our services actually have more than just one trigger, and you hence need to unify the activation queue to avoid duplicate services running.

D-Bus is not a very capable process babysitter. systemd however is. D-Bus only can do bus-based activation. systemd has many more triggers. Which is why we unified process management in systemd, and tightly integrated D-bus with it, and not the other way round.

"DBus services also make much richer dependencies expressible - ones that are simply impossible with systemd, in any sane way." -- this comment is just wrong, as one core feature of systemd is bus-based activation -- what you can do with D-Bus activation is a subset of what you can do with systemd.

So, to answer your question "how does systemd fit in?" -- it fits in perfectly, as it covers the various kinds of activation you asked for just fine, and at its very core.

I am pretty sure we leave some problems unaddressed with systemd, after all we are just human and cannot make everybody happy. But I do believe we actually cover the greatest part of what we need in an init system for Linux. But we are all ears to add whatever is needed, if it makes sense for the general case.

Lennart

The word "socket proxy" is misleading, as it suggests that systemd was actually proxying every single byte from the network to the actual applications. This is not what happens. systemd hands off the real socket fd to the spawned applications and thus during runtime the performance is identical to services that called socket() themselves.

My comments regarding "events" in systemd and upstart refer to the fact that in upstart an "event" is a first-level object that is at the core on what it does and which is what the admin works with. While in systemd we internally use an event-based API such as epoll(), this is hidden to the outside and our first level objects are our "Units" and the dependencies between them.

I think there's little point in creating a library for spawning processes as you need a (system-wide) runtime component for a lot of the stuff that a good baby-sitter does, such as collecting info about crashes and suchlike. Also, it is essential that services are detached from the code that actually spawned them. That makes it important to fork them off some central process, so that they inherit a clean execution environment. Due to that you absolutely *want* this to be forked off PID 1.

And sure, it is impossible to foresee all ways people might want to use their computers in. But that's not a problem. We cover what makes sense for the base system. If people run complex application servers such as Java on top of them they can do that, there's no need in centralizing their process management too. We do not want to lose focus.

systemd is a very dynamic in itself, however it is not a vehicle to make other daemons more dynamic. It is also not a humongous abstraction effort to encode the entire system state in a single place. Instead, we focus on mount, device, process management and a few things around it. But that's it. We don't do lose focus and we want to have a very clearly defined set of goals what we want to do and what not. Or to put this in different words: if applications want to follow power states or track location then they should not talk to systemd about this, they should go directly to upower, to geoclue or whatever other service might be a good candidate.

(claiming one pedant point, since I'm certain you already knew this!)