[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: init system thoughts

On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson <cjwatson@debian.org> wrote:

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

start on dbus-started and /* dbus signal received */
stop on dbus-stopped or /* dbus signal not received */

So this is cool. NetworkManager is started not simply when it is able to start, but also when it needs to start. It stops when dbus stops (its dependencies are unavailable) or when it is not needed by anyone. What is great about Upstart's model is its flexibility. Example:

start on dbus-started and /* dbus address accessed */
stop on dbus-stopped

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.

start on syslog-started and /* socket event aimed at dbus */
stop on syslog-started or /* no socket events toward dbus */

Now, this changes things around, and the NetworkManager job needs to modified to not wait for dbus to start, but just access the socket and let Upstart automatically start dbus following that event.

start on dbus SIGNAL=....
stop on dbus-stopped

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.

Good night,
Cameron Norman

Reply to: