On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson <cjwat...@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