LPC: Upstart 1.0 plans: manifesto for a new init

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 other distributions.

While Greg 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.

Events are 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 cron? 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.