Bug#727708: init system thoughts
Cameron Norman <camerontnorman@gmail.com> writes:
> On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
>
>> 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):
>>
>
> I think you raise a lot of good points in this email, but here you are
> saying something which may demonstrate your (understandable) confusion
> about the Upstart event model. Upstart does not treat dependencies as
> events. Often times, Upstart //jobs// treat dependencies as events (and the
> ones you wrote below do), but events do not signal a dependency. Just
> because you said that jobOne starts with jobTwo does not mean that jobOne
> needs jobTwo, just that during boot up jobOne will start with jobTwo. To
> express a dependency, jobTwo needs to have a "start on (event where I am
> needed)". If, for example, jobOne depends on a dbus interface of jobTwo,
> then jobTwo could have a "start on dbus ..." to show that dependency.
I think I understand what you're saying, thanks for the explanations!
However, I can't say that this improved understanding has improved my
opinion about upstart. If I understand correctly, this means that either
a) every upstart job definition needs to explicitly list every possible
way in which another service may depend on it (and, furthermore,
every possible such dependency needs to have upstart integration so
that it can actually be used as an event)
or
b) a package providing jobOne that depends on jobTwo from another
package needs to patch the *other* package's configuration to add the
dependency information to jobTwo's definition.
Neither of this sounds appealing to me at all, especially compared to
systemd, where all you have to do is drop a Requires= line into jobOne's
configuration.
> Basically, to express dependencies in Upstart you express all the ways
> a job is needed inside of that job, not inside others. That said,
> Upstart developers and Ubuntu developers do not use Upstart this way
> and write jobs like you did below, so an Upstart system will most
> likely not act like I explained above (however this is not an inherent
> flaw in Upstart).
Well, so what is the proper way to encode a dependency in an upstart job
for Ubuntu (and presumable Debian) then? Apparently the proper way is
extremly tedious and not used by anyone, and the other way isn't able to
satisfy dependencies.
Also, I would think that your statement above is a rather strong
indication that this is *not* the upstart is meant to be used. Could the
upstart developers comment on this?
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.«
Reply to: