Ubuntu and Fedora Replace init with Upstart - page 2
Init: the Old Way
The crucial point about upstart is that it's event-based rather than level-based (init, as described above, is level-based). Services can be started or stopped in response to other events occurring on the system: any other events, anywhere. So a service can be set to respond to an event generated by a piece of hardware being plugged in, for example. It can also handle restarting services if they die unexpectedly (which init can't do).
Instead of treating a particular level (or a particular piece of software) as a goal, and starting services to correspond with that, upstart
starts off with a single 'startup' event, and carries on as far as the available hardware indicates, and as far as the event chain from 'startup' implies. (Note that you can set services to start when another service is started, which can also extend the startup chain.) You can also use events to start up services in blocks – there'll be an explanation in the next article of how to run your old init system with upstart for an easy move over.
'Events' are strings, which can include environment variables as part of themselves if more information is needed. Events trigger jobs, which are defined in the /etc/event.d directory. A simple job could be a binary, or a shell script; more complex jobs can include code to run before a job is started and/or after it finishes.
You can define and set up any events you want, and configure jobs to run in exactly the circumstances you want. This makes the upstart system much more flexible: it can respond to the changes in circumstance of a modern system without manual intervention (whereas with init your only options are changing levels, or manually running one of the scripts in /etc/init.d/).
This may still sound a little confusing! In the next article, I'll give some examples of how upstart works, how you can easily run a combination upstart/init system, and what you can put in upstart scripts.