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. 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). I would also like to note that launchd acts the same exact way as I have described and had similar limitations. Furthermore, SystemStarter (Apple's previous init) acted in a very similar way to systemd: "The hardest part to manage during a launchd boot is dependencies. SystemStarter had a very simple system of dependencies that used the "Uses", "Requires", and "Provides" keys in the plist of a startup item. There are two main strategies when creating launch dependencies on [OS X] . Using IPC will allow the daemons to talk amongst themselves to work it out, or you can watch files or paths for changes. Using IPC is much more subtle than the SystemStarter's keys and requires more work from the developer, but it may* <https://en.wikipedia.org/wiki/Wikipedia:Citation_needed>*lead to cleaner and quicker startups." -- https://en.wikipedia.org/wiki/Launchd#launchd I still think your points are relevant, however, because Upstart in Ubuntu acts in the same way as the below jobs, and Debian will most likely inherit that behavior if it uses Upstart. Happy New Year, Cameron Norman $ 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.« > > > -- > To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/87y52zuuaw....@vostro.rath.org > >
