On Mon, Dec 30, 2013 at 07:26:23PM -0800, Russ Allbery wrote: > > (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.) > I am new to both models. I'm not very fond of the upstart model. > Lennart had a comment on this point that I thought phrased the problem in > an interesting way: both systemd and upstart deal with the same data, but > with systemd, the full dependency tree is precalculated and exists as > state within the init system. With upstart, behavior is dynamic and to > some degree emergent: you know who is listening to what signals, but you > can arbitrarily introduce signals, and you're dealing with a message bus > rather than a dependency tree, so you're reacting to things as they happen > on the bus. In systemd, you can dump everything that can possibly happen > and work through the state transitions by hand if needed, with the > possible exception of unexpected device events (which are horribly > important in some cases -- don't get me wrong -- but which are > uninteresting in a lot of common debugging scenarios). I think it's > somewhat harder to do that with upstart, where events are generated more > dynamically. So for a concrete example of where I think upstart's model lets us get things right at boot that systemd's dependency model does not (or at least, this hasn't been done yet in Debian), I'd like to direct your attention to /etc/network/if-up.d/upstart . Conceptually, there are certain kinds of services in a distro context that we don't want to start by default until "the network" is up - because they aren't set up for socket-based activation, or might need to bind to particular addresses/interfaces and not fall back gracefully, etc. Of course if we were writing all our services according to best practices, we wouldn't have to worry about this, as the service would just handle this gracefully (or maybe hand the complexity off to the init system for socket-based activation - but then what does init do with a request for a socket address that's not available? cycles within cycles, etc). But in the real world, we have a lot of services that we just want to start in runlevel 2 and be able to trust that the network and disk are sorted. This is the classic guarantee that sysvinit gave us pre-udev, but it's fallen apart since then because a fast system can get all the way through rcS before the kernel has even managed to enumerate all the network devices. Upstart (as implemented in Ubuntu) restores this guarantee (with provisions for failsafe booting in the case of a wrong network config), and it takes advantage of upstart's capability of sending arbitrary signals to do so. I can see how one could implement the equivalent of upstart's static-network-up event on systemd, using generators. But what would the equivalent to /etc/init/failsafe.conf look like? I think this would be very difficult to express in systemd language, yet it's altogether vital for providing a boot that is both reliably ordered, and recoverable in the event of problems. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature