Colin Watson <cjwatson@debian.org> writes:
> 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.)
For what it's worth, I consider myself new to both the upstart and the
systemd model, and for me the upstart event model has been pretty much
the only reason to prefer systemd over upstart (though after reading
Russ' opinion, that has changed a bit).
For me, upstart was actually the reason for me switching from Debian to
Ubuntu for a while. I am less familiar with systemd, so it may well be
that I underestimate the complexities of the systemd model. However, I
am very certain in my dislike for the upstart approach.
My first point of criticism has already been described by Russ, but
maybe I can make it clearer by giving an example. In my opinion, the
following job looks completely harmless, and should not result in an
unbootable system (but at least on Ubuntu 13.10 it does, you have to
reboot with init=/bin/sh and remove/fix the evilJob.conf file):
$ cat evilJob.conf
start on (mounted MOUNTPOINT=/var and started lightdm)
stop on runleves [016]
respawn
script
exec /bin/sleep 60
end script
I believe that the equivalent systemd unit (where dependencies are
specified with Requires=) works just fine. It is not clear to me how
this can be "incrementally fixed" in upstart without fundamentally
changing the design.
My second point is that by treating dependencies as events, upstart does
not seem to truly recognize dependencies as such and is then unable to
resolve them. For example, with the following two job files (created
according to the upstart cookbook, 6.32.2):
$ cat jobOne.conf
start on (starting jobTwo and runlevel stop on runlevel [016])
stop on runlevel [016]
respawn
script
exec /bin/sleep 60
end script
$ cat jobTwo.conf
start on runlevel [2345]
stop on runlevel [016]
respawn
script
exec /bin/sleep 60
end script
I can type "service start jobOne", and upstart will willingly start
jobOne without starting jobTwo, or doing anything about the unfulfilled
dependency (not even a warning):
root@ubuntu-kvm:/etc/init# service jobOne status
jobOne stop/waiting
root@ubuntu-kvm:/etc/init# service jobTwo status
jobTwo stop/waiting
root@ubuntu-kvm:/etc/init# service jobOne start
jobOne start/running, process 3177
root@ubuntu-kvm:/etc/init# service jobTwo status
jobTwo stop/waiting
(on Ubuntu 13.10).
As I understand, a systemd unit with "Requires=jobTwo" will not start
without jobTwo running.
I guess this could be fixed by hardcoding a special treatment of the
"start on starting" event, but that would effectively be equivalent to
introducing a new kind of "depends on" stanza, and thus acknowledge that
the "everything is an event" model doesn't quite work.
Best,
Nikolaus
--
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
»Time flies like an arrow, fruit flies like a Banana.«
Archive: 87y52zuuaw.fsf@vostro.rath.org" target="_blank">http://lists.debian.org/87y52zuuaw.fsf@vostro.rath.org
--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org