On Wed, Jan 1, 2014 at 5:09 PM, Nikolaus Rath <nikol...@rath.org> wrote:
> 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): > >> > > > > 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) > Pretty much all IPC mechanisms have integration into Upstart, so a lot of dependencies are covered. > 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. > Yes. The patch would, however, be limited to a "or (...)" in the start on section. So it is not like the patch is going to change a ton. > 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. > I agree, especially when one can have a "Requires=*.socket" or "Requires=*.bus" and get the same benefits. > > 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? > > > Steve Langasek does not consider IPC activation to be integral to Upstart, so I assume he may disagree with me in some ways here. I am curious how he (and other Upstart devs) thinks your jobOne and jobTwo situation should be handled. Cheers, Cameron > > 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.« >
