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

Re: Really, ...

On Thu, Nov 29, 2012 at 10:32:46PM +0100, Bernhard R. Link wrote:
> > > Claiming that it will work for everyone and that
> > > anyone not being able to name a problem existing now has no arguments
> > > does not help.

> > Do System V Init or Upstart work in EVERY single use case?

> Actually, all my experiences with upstart has been when it does not
> work. And then it was always a pain to work with. So in my experience
> System V Init is quite superior to Upstart.

> And the big advantage of System V Init is that everyone can diagnose
> and fix it. Everyone knows how to add some echo lines to find out where
> something is happening. Having the logic available in some easy
> well-known and very extensible syntax means I could easily adopt it
> and make it fit my needs even more I understood what most of this stuff
> it. And with all the nice properties descriptive systems have and as
> much as I love them, nothing beats discoveribility, debugablity and
> extendiblity of imperative programming.

As true as that may be, the happy declarative syntax is not the only
advantage of upstart (or systemd) over sysvinit.  Sysvinit's very static,
linear notion of runlevels is not well adapted to the modern reality of an
event-driven kernel.  Ask the maintainers of packages like lvm2, cryptsetup,
open-iscsi, or multipath-tools how much fun this is.  It may be easy with
init scripts to know where the problem is, but that's cold comfort when the
architecture prevents you from sanely fixing that problem.

Boot speed is actually a proxy metric for this.  Nothing slows down the boot
of a system quite so well as a 'sleep' call in the middle of your init

(squeeze)vorlon@becquer:~$ cat /etc/rcS.d/* | grep -c 'sleep[[:space:]]\+[0-9]\+'

Why are those sleeps there?  Because the use of init scripts ensures that
we're always racing the kernel, instead of being able to respond directly to
events when they happen.  Nearly every one of those sleeps represents *two*
bugs: the bug the maintainer noticed that caused them to add the sleep as a
workaround, and the remaining bug of the race condition that the maintainer
hasn't yet tripped over and needed to fix.

So given this fundamental limitation of the design of sysvinit, do you have
any suggestions for how upstart could be improved to be less of a pain to
work with?  I'm sure at least some of this inevitably comes down to what
people are familiar with; but if there are things that you think are
fundamentally less debuggable about upstart that we should fix (and I
already have a few of these on my own list), I'd be interested to hear about

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: