Ubuntu's Success Story: the Upstart Startup Manager (Linux Boot Camp p.2)
Controlling Boot Sequence, What is Event-Based
Akkana Peck
Thursday, April 8, 2010 11:32:09 AM
Boot Camp Part I explained how Linux boots, using the old "SysV init" system of scripts. But some modern Linux distros have been gradually migrating to a newer model, called Upstart.
Upstart has been around since 2006, but it's only in the last year or so that it's taken a major role in booting distributions like Ubuntu and Fedora. Debian and OpenSuSE are reportedly joining in soon, while it's available as an optional component on most other distros. No distro uses it as the sole boot method yet: even Fedora 12 and the upcoming Ubuntu 10.04 keep a lot of functionality in SysV scripts.
An event-based model
The normal SysV boot process is synchronous -- meaning things happen one at a time, one after the other. First you run S10sysklogd, and only when that's finished you can start running S11klogd. If anything in the boot process takes a long time, everything else has to wait.Upstart, in contrast, is event based. An "event" can be something like "booting" ... or it can be a lot more specific, like "the network is ready to use now". You can specify which scripts depend on which events. Anything that isn't waiting for an event can run whenever there's CPU available.
This event-based system has another advantage: you can theoretically use it even after the system is up and running. Upstart is eventually slated to take over tasks such as or plugging in external devices like thumb drives (currently handled by udev and hal), or running programs at specific times (currently handled by cron).
Currently, however, Upstart is used primarily for booting and shutdown, and it's not clear when we'll see it used for other purposes.
New directories
Upstart eschews the old /etc/init.d and /etc/rcN.d in favor of a new directory containing "job definition files". And here's a point of confusion: it doesn't have a standard name.On most systems, including Fedora and released Ubuntu systems, Upstart uses /etc/event.d. But in Ubuntu's upcoming release that changes to /etc/init. Yes, that means Ubuntu 10.04 systems have both /etc/init, for Upstart, and /etc/init.d, for the old SysV files. Not only that, but if you upgrade from an earlier version of Ubuntu and you've put anything nonstandard in /etc/event.d, you'll have to migrate it by hand -- the upgrader does not do any migration (bug 402759.)
I mentioned that Upstart doesn't use /etc/init.d. But all Upstart-using distros still include that directory. Some of the files in it are regular SysV Init scripts that haven't been migrated yet. But some services that have migrated maintain a link from /etc/init.d to /lib/init/upstart-job. If you run one of those, it works, but it prints a warning first:
$ sudo /etc/init.d/dbus restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service dbus restart
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the restart(8) utility, e.g. restart dbus
Boot sequence
How does the boot sequence change with Upstart?The beginning of the boot sequence is still the same. The computer's BIOS boots grub (or another boot loader) from the disk; grub loads the kernel and then passes control to the init process.
But on an Upstart machine, init comes from upstart. Instead of running a master rc script that calls the scripts for a specific runlevel, Upstart's init takes jobs from its job directory.
Job definition files
A typical Upstart job definition file looks like this:$ cat /etc/event.d/hostname.conf
# hostname - set system hostname
#
# This task is run on startup to set the system hostname from /etc/hostname,
# falling back to "localhost" if that file is not readable or is empty and
# no hostname has yet been set.
description "set system hostname"
start on startup
task
exec hostname -b -F /etc/hostname
In this simple case, the hostname job runs when Upstart sees a startup event. Events can be more detailed than that, For instance, Upstart knows about runlevels. The file rc2.conf, whose job is to run all those old SysV files in /etc/rc2.d, includes this:
start on runlevel 2
stop on runlevel [!2]
udev.conf includes: start on virtual-filesystems
stop on runlevel [06]
virtual-filesystems is an event indicating that filesystems such as /dev and /proc have been mounted. It's sent by another Upstart job: $ cat mountall.conf
# mountall - Mount filesystems on boot
#
# This helper mounts filesystems in the correct order as the devices
# and mountpoints become available.
description "Mount filesystems on boot"
start on startup
stop on starting rcS
expect daemon
task
emits virtual-filesystems
emits local-filesystems
emits remote-filesystems
emits all-swaps
emits filesystem
emits mounting
emits mounted
[ ... rest of script ]
All these signals will be emitted when the mountall job completes successfully. Then Upstart can start jobs like udev that are waiting for one of those events. Jobs can depend on more than one event:
