How did this guy test systemd exactly?

I don't think I'm completely ignorant about what systemd is about:

1. Centralise the code for daemon creation and process management, and try get rid of things that do this themselves - often badly.

2. Have systemd to act as a socket proxy, auto-activating the services as required (ala ye olde Unix inetd, or Java rmid, etc). This allows many dependencies to be automatically worked out (static dependencies are made "redundant" is the claim), and so allow parallel launching. Activation is event-driven (see below).

I just noticed that the very latest DBus 1.4.0 now has support for handing off any spawning of services down to systemd - which is nice and addresses some of my concerns about the overlap between the two.

Your objection to events in upstart is that dependencies are propagated as a number of different "events", and it doesn't work. Systemd doesn't use this model for dependencies, however I presume you would still agree activation in systemd is event-driven (i.e. on the event of activity on the proxied fd). Reading service state and subscribing to events for changes in that state is also you wouldn't disagree with (provided you can read the current state and subscribe to new events in a race free manner). The latter is generally what I mean by event-driven, including the possibility where there is no state.

My concerns:

On 1: It's great to factor out and centralise code, but I'm not sure systemd will always be able to handle *all* process management directly. There's all kinds of weird cases people will want to handle, there are all manner of userspace service management thingies out there, from the more obvious ones (*inetd, rmid) to all kinds of custom ones. You can try generalise and handle most of them, but likely at some cost in simplicity (internally and admin visible - e.g. already, the docs for systemd service files contain an abundance of options), but it seems infeasible for systemd to be able to anticipate all possible demands of systems that want to spawn processes. Perhaps it'd be nice to have this stuff in a system *library*, useful to both systemd and other processes? E.g. systemd now supports DBus, but what about, say, Java rmid, which needs to be runnable as, and to configure new RMI services (for which it forks a separate JVM), as a non-privileged process; what about end-user DBus buses spawning services?

On 2: I'm not sure this is right. While there may be a number of services where it happens to work out, in the general case many dependencies are not visible*. That systemd has acquired various ways to manually specify ordering and activation is proof of this. Obviously there are lots of events that require richer systems to deal with, e.g. by modifying applications to publish state and reacting intelligently to changes in other applications' state (with some suitable IPC like DBus in there to glue it together). Essentially, I think even with systemd, you're going to still have a mass of files that have to describe properties of and relationships between services. That's info that's easy to get wrong, and otherwise can drift and get out of sync.

To summarise:

- I'm not sure it's healthy to centralise service management in 1 process. I suspect there'll always be need for additional specialised, sub-system centric process managers. (One may disagree on "need", but others will perceive such needs, and hence such will exist). So why not centralise the code in a library, so it can be used by /all/ process managers on the system?

- I can see how socket proxying is attractive, as it's a relatively easy change, but how much encoding of client properties can it really avoid? The only way to truly get dependency free bootup surely requires updating the applications to behave better?