Hello,
I am aware that this bug already has a lot of emails in it, but I think
the issue below is important enough to warrant a
*ping*
to the upstart developers. It would be great if someone could comment on
this.
Best
Nikolaus
Nikolaus Rath <nikol...@rath.org> writes:
> Cameron Norman <camerontnor...@gmail.com> writes:
>> On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath <nikol...@rath.org> wrote:
>>> Colin Watson <cjwat...@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).
>>
>> 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?
--
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.«
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
