Let's make two things clear about Upstart,
a proposed replacement for the Linux "init" process.
First, it's not there to speed up boot, and second,
it's not intended to parallelize startup. "Upstart is
not for what most people think it is for," said its
author, Scott James
Remnant, in a talk in the dbus miniconference at
the Linux Plumbers Conference. What it is there for
is to expand the capabilities of "init" on Linux,
replace some scripts and workarounds with rules
that are intended to be easier to understand and
modify, and enable future improvements. Remnant is
a Canonical employee, and Upstart is in Fedora
as of version 9, making it a welcome example of a
Canonical-sponsored project finding its way into
Kroah-Hartman mentioned a list of core software on the
Linux platform in his Plumbers Conference talk,
"the one thing he never put in there was init,"
Remnant said. The Linux init, originally by Miquel
van Smoorenburg, has been unchanged for years, and
is modeled on the System V Unix init, which is even
older. Instead of updating it, Remnant says that, for
too long, distributions have just worked around it.
The startup process has traditionally consisted
of shell scripts, started by init, but containing
workarounds and extensions accumulated over the years.
For example, Debian has a wrapper program called
start-stop-daemon, that manages PID files, to keep
track of what process ID a daemon process ends up with.
Upstart handles that itself.
Current features of upstart include sending
notifications for system events, for example, when a
service starts; eliminating race conditions, by
offering dependency tracking; and removing some
service startups from the critical path for boot,
again by handling dependencies. Upstart allows a
distribution or sysadmin to spell out the critical
path in a script, and also specify dependencies.
Tracking dependencies allows distributions to
eliminate "sleep" loops from the boot sequence, and
instead take actions based on events.
not limited to the runlevel changes familiar to
sysvinit users, but can depend on other things on
the system. But what other things?
Future directions for Upstart could be ambitious.
For 1.0, Remnant is considering adding the
ability to do tasks based on cron-like criteria
such as "hourly." But should upstart really replace
Another possibly useful direction would be an "idle"
event. The Common Unix Printing System (CUPS) is a
service that makes sense to start "30 seconds before
the user thinks of clicking on the print button,"
he said. CUPS is not in the critical path for boot,
but needs to be running to detect printers before
the user needs them. Should it be possible to start
non-critical services when the system becomes idle?
Even though fast boot isn't the goal of upstart,
Remnant is optimistic about being able to help.
Some of the slow booting problems that Arjan van de
Ven and Auke Kok identified at the conference are deep
in the weeds of nested scripts, and might be smoked
out by a simpler init layout. "To make boot fast we
have to do a bunch of different stuff. it makes it
easy for us to do the real work," Remnant said.
to post comments)