- Denial: System V Init
- Anger: Upstart
- Bargaining: Backward Compatibility
- Depression: udev
- Acceptance
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Bargaining: Backward Compatibility
Unfortunately, most system startup today is still managed by classic init scripts. Currently, all you'll find in the Upstart scripts (located under /etc/event.d) are scripts that manage each classic runlevel, along with a few other basic scripts.
Here's an example of an Upstart script that's triggered when the runlevel changes to 2:
start on runlevel 2
stop on runlevel [!2]
console output
script
set $(runlevel --set 2 || true)
if [ "$1" != "unknown" ]; then
PREVLEVEL=$1
RUNLEVEL=$2
export PREVLEVEL RUNLEVEL
fi
exec /etc/init.d/rc 2
end script
The syntax is pretty straightforward. Certainly it's simpler than most init scripts I've written. The start on and stop on lines define the events that trigger the script, the console output line tells the script to direct any output to the console, and the script section defines a shell script to execute.
Scripts can be even simpler. The following Upstart script is triggered by an event we defined, called bounce:
on bounce exec echo --Bounced--
The first line defines which event triggers the script; the second line defines the command to execute. To trigger the script, I can use the initctl program to generate the bounce event:
# initctl emit bounce --Bounced--
Since Upstart scripts can be launched by other events, Upstart can run its scripts asynchronously. System V init scripts launch one at a time, but multiple Upstart scripts can run in parallel. This doesn't automatically mean that the system will boot faster, but it could be possible.
Another advantage: Since Upstart is PID 1 on the system, it can track the status of any script it launches, and report the PID of all of its scripts with the initctl status command. No longer will you have to maintain annoying lock files in /var/run/ to know what PID a process has so you can stop it later. This also means that it's trivial to set any Upstart script to respawn automatically. Since it keeps track of all of its scripts, Upstart knows whether any script exits normally or with an error, and can respawn when appropriate.
Unfortunately, we can't take full advantage of all of Upstart just yet. Even though other distributions such as Fedora also use Upstart, it's still a massive undertaking to replace all of the current init scripts with Upstart scripts. This is the ultimate plan, but it will be some time before we're on a 100% Upstart system. Of course, once we're on such a system, we won't really need runlevels anymore, since we can just trigger events based on the current state of the system.
Upstart also aims to replace cron and at eventually. Shocking? Yes. But this plan makes sense. After all, cron and at launch programs based on a specific type of event—the time becoming a particular value. There are even plans to allow user-created Upstart scripts.