Bug#727708: init system thoughts

The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things actually happen in reality; dependencies are artificial constructions on top of them, and making them work requires the plethora of different directives in systemd (e.g. Wants, which is sort of a non-depending dependency) to avoid blocking the boot process on a single failing service. Yes, there are some bugs possible in the Upstart design, but I don't agree that those are world-ending fundamental issues and I think they're generally incrementally fixable. The systemd design appears to me to expose far more complexity to the user writing unit files, and I think it's important that their mental model be as straightforward as possible. (Now, I've been working with Upstart's model for years, and it's now a pretty fundamental way of how I think of system operation; so if people who are new to *both* models rather than partisans of one side or the other consistently tell me that the systemd model is easier to grasp, then I'll listen.)

I would like to give my view of the event vs. dependency model. I will declare my conclusion up front: Upstart's event model is, in my opinion, more flexible, and much more compatible with socket activation than systemd's dependency model (which is ironic, since Upstart does not stress socket activation, and systemd does).

I will start with an example including syslog, dbus, and NetworkManager. One way a distribution developer would write these job files is by saying "start on syslog-started" and "stop on syslog-stopped" for dbus. Although this may seem like the obvious way to write the job, it is not the most efficient. This is what I will call an "always on" job. Whenever it is possible for this job to be on (its dependencies have started, and the job is enabled) it will be on. This can cause slow boot, because a ton of jobs are being started that do not need to be. This is the fault of //the distribution developer//, not Upstart itself. Now, lets imagine this developer stopped for a second to think before denouncing Upstart as inefficient crap. He knows that his dbus job was probably not efficient, and he wants to try to make a more efficient NetworkManager job. So, the developer crafts a

This starts NetworkManager when its services are required, but then keeps it running even after they are not, until it can no longer provide its services. This may be desirable in some situations (maybe starting and stopping nm a lot is unwanted), and shows how this event model puts more control in the job, rather than a config file. Now lets say that developer realizes how powerful the event model is, and goes back to reimplement his dbus job. He/she wants dbus to be running only when its services are needed.

I think this usage of Upstart's event model is incredibly superb, and much more understandable and usable than systemd's socket and bus activation model. Although systemd's declarative syntax is simple, I think it offers too little flexibility and does not reflect the realities of the system to the unit, which makes the declarative syntax an abstraction that needs to be understood by the admin, or it will be misused. Furthermore, with a little work put into Upstart's socket event bridge and socket handling (which should not be a problem since the infrastructure is already there), the boot time speed ups and socket based activation model of systemd can be achieved with only a little effort, and considerably more flexibility.