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). 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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org