Ubuntu’s Success Story: the Upstart Startup Manager (Linux Boot Camp p.2) – Controlling Boot Sequence, What is Event-Based – Tutorials – LinuxPlanet

Ubuntu’s Success Story: the Upstart Startup Manager (Linux Boot Camp p.2)

Controlling Boot Sequence, What is Event-Based

  • April 8, 2010
  • By

    Akkana Peck

BootCamp Part Iexplained how Linux boots, using the old “SysV init”system of scripts. But some modern Linux distros have been graduallymigrating to a newer model, called Upstart.

Upstart has been around since 2006, but it’s only in the last year orso that it’s taken a major role in booting distributions like Ubuntuand Fedora. Debian and OpenSuSE are reportedly joining in soon, whileit’s available as an optional component on most other distros.No distro uses it as the sole boot method yet: even Fedora 12 and theupcoming 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 startrunning 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 isready to use now”. You can specify which scripts depend on which events.Anything that isn’t waiting for an event can run whenever there’sCPU available.

This event-based system has another advantage: you can theoretically useit even after the system is up and running.Upstart is eventually slated to take over tasks such asor plugging in external devices like thumb drives (currently handledby udev and hal), or running programs at specific times (currentlyhandled 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.din 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 releasethat changes to /etc/init. Yes, that meansUbuntu 10.04 systems have both /etc/init, for Upstart, and/etc/init.d, for the old SysV files. Not only that, butif you upgrade from an earlier version of Ubuntu and you’ve putanything nonstandard in /etc/event.d, you’ll have to migrateit by hand — the upgrader does not do any migration(bug402759.)

I mentioned that Upstart doesn’t use /etc/init.d. But allUpstart-using distros still include that directory. Some of the filesin it are regular SysV Init scripts that haven’t been migrated yet.But some services that have migrated maintain a link from /etc/init.dto /lib/init/upstart-job.If you run one of those, it works, but it prints a warning first:

$ sudo /etc/init.d/dbus restartRather than invoking init scripts through /etc/init.d, use the service(8)utility, e.g. service dbus restartSince the script you are attempting to invoke has been converted to anUpstart 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’sBIOS boots grub (or another boot loader) from the disk; grub loadsthe 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 scriptsfor a specific runlevel, Upstart’s init takes jobs from its jobdirectory.

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 startuptaskexec hostname -b -F /etc/hostname

In this simple case, the hostname job runs when Upstart seesa startup event.

Events can be more detailed than that, For instance, Upstart knowsabout runlevels.The file rc2.conf, whose job is to run all those old SysV files in/etc/rc2.d, includes this:

start on runlevel 2stop on runlevel [!2]

udev.conf includes:

start on virtual-filesystemsstop on runlevel [06]

virtual-filesystems is an event indicating that filesystems suchas /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 startupstop on starting rcSexpect daemontaskemits virtual-filesystemsemits local-filesystemsemits remote-filesystemsemits all-swapsemits filesystememits mountingemits mounted[ ... rest of script ]

All these signals will be emitted when the mountall job completessuccessfully. Then Upstart can start jobs like udev that are waitingfor one of those events.

Jobs can depend on more than one event: