[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: init system thoughts

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.

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

Reply to: