[clue-tech] upstart

dennisjperkins at comcast.net dennisjperkins at comcast.net
Tue Sep 9 12:35:54 MDT 2008


 -------------- Original message ----------------------
From: "Michael J. Hammel" <mjhammel at graphics-muse.org>
> On Mon, 2008-09-08 at 20:57 -0600, Kevin Fenzi wrote:
> > That said, I agree in some cases new stuff that provides no advantages
> > or is not mature enough gets shipped. It happens. I really can't see 
> > why anyone would argue thats the case with SysVinit/upstart however. 
> 
> I just read the Wikipedia entry (http://en.wikipedia.org/wiki/Upstart),
> the upstart web site (http://upstart.ubuntu.com/) and the upstart design
> spec (http://upstart.ubuntu.com/misc/upstart.pdf) and, while there is
> plenty describing what Upstart will be able to do, I still see little
> that says SysVInit (or init) was broken and needed to be replaced.  
> 
> On the upstart wiki there is the link
> (https://wiki.ubuntu.com/ReplacementInitDiscussion) to some discussion
> in 2005 about why upstart is necessary.  This at least offers some
> rational and use cases to back up the need for upstart.  Unfortunately,
> with a couple of exceptions, the use cases are pretty poor and can be
> handled by existing tools fairly easily.  The most compelling argument
> is boot speed.  If upstart is the only solution to this problem, so be
> it.  But I doubt it.  Most interesting here is the section titled BoF
> Agenda and Discussion (at the bottom of the page).  There is some truth
> to the problems that exist with dealing with dying daemonised processes.
> I'm not sure this warrants replacing init, but maybe.  And a parallel
> boot vs a serial boot process would certainly help boot speed.  Some of
> this can be handled with boot dependencies.  But while the arguments
> here explain the problems that exist they do not explain why the
> existing solutions cannot be evolved to handle them. 
> 
> So again, I'm not convinced this is a good idea.  While replacing
> multiple application layer job schedulers seems a possibly useful idea
> simply for the sake of configuration, where is there anything that
> says /sbin/init is broken beyond repair?
> 
> I'm open to changing my mind and saying I was wrong.  But I won't follow
> blindly.
> -- 
> Michael J. Hammel                                    Principal Software Engineer
> mjhammel at graphics-muse.org                           http://graphics-muse.org
> ------------------------------------------------------------------------------

One problem is a lack of documentation.  I've spent some time searching the web for information and I've got some notes assembled.  Some of it is clear.  Some requires testing to make it clear.  Some of this confusion seems to be due to changes in upstart.  I really wish that people would put dates on their blogs and documents.  It would make it easier to know that I am looking at obsolete information.

The use cases seem to have been hastily thrown together.

Dependency information seems to be the traditional means of trying to modify init.  I think a few people were already exploring this in the late 90's or in 2000.  This can affect manual starting and stopping of services as well as startup and shutdown.  If you want to start a service, are all of its dependencies running?  If not, start them.  If you want to stop a service, does it affect other services?  If so, do you still want to stop the service and every affected service?

Upstart's use of events might be due to USB, which is event driven.  Plug in a device.  Unplug it.  This causes events in the USB hardware which propagate to the kernel.  And out to udev, if you are running udev.  After udev has created or destroyed a device node, it generates an event and sends it out via D-Bus to any interested program.  This would be Nautilus on Gnome, which starts gnome-mount to mount a USB memory device.  KDE's window manager might do the same thing, but a different program might handle this.


Linux seems to be converging on udev/dbus/HAL to handle hot-pluggable devices, with DeviceKit to replace HAL in the goal of "making things just work".  This triad impinges on fstab, /mnt, and whatever variant of init is being used (sysvinit, initng, runit, upstart).  I know of two daemons that attempt to handle LAN and wireless connections to make networking just work.  This might affect the network bootscript.

In some cases, such as servers, or security-sensitive sites, some of this automatic operation might not be wanted.


I like my computer to boot fast.  Ubuntu is slow compared to Arch.  I think Arch does not start as many services.


More information about the clue-tech mailing list