A look at Ubuntu Upstart
Monday, May 04, 2009 11:14 AM
Ubuntu's Upstart system is an event-based replacement for SysV init that handles the starting of tasks and services during boot.
When I was working on the Annvix project, I was fascinated with how the system booted and services were started.
This led to an eventual rewrite of initialization scripts and the use of runit instead of the traditional SysV init. The results were fantastic: a fast booting system with services starting in parallel and a series of scripts to start and stop the system with a small footprint and amazing speed.
When I recently installed Fedora Core 10, I found that one of the new features was the use of Ubuntu"s Upstart, a SysV init replacement system.
I've taken the opportunity to poke at it a little bit and see how it compares to runit and SysV init, especially in light of the fact that a number of features it does have or plans to have mimic a lot of the things that made runit and supervised services so appealing.
According to Canonical, Upstart is an event-based replacement for SysV init, that handles the starting of tasks and services during boot. It stops them during shutdown, and supervises them while the system is running. From an end-user perspective, the system boots no differently.
The venerable /etc/inittab still exists, but all it does is indicate which runlevel is the default. Everything else is handled via configuration files in /etc/event.d/ (on Fedora) and /etc/init/jobs.d/ (on Ubuntu).
These files replace certain lines in /etc/inittab; for instance the /etc/event.d/tty1 file contains:
start on stopped rc2
start on stopped rc3
start on stopped rc4
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6
respawn
exec /sbin/mingetty tty1
Whereas on a SysV init system, an equivalent line in /etc/inittab would read:
1:2345:respawn:/sbin/mingetty tty1
Both of these indicate that if tty1 dies, it should be restarted. As is evident, this works with SysV init:
# ps ax | grep tty6 | grep -v grep
11656 tty6 Ss+ 0:00 /sbin/mingetty tty6
# kill -9 11656
# ps ax | grep tty6 | grep -v grep
11676 tty6 Ss+ 0:00 /sbin/mingetty tty6
You can tell, due to the differing PID, that init has restarted the service.
Unfortunately, Upstart in FC10 is not quite so successful:
# ps ax | grep tty2 | grep -v grep
2502 tty2 Ss+ 0:00 /sbin/mingetty tty2
# kill -9 2502
# ps ax | grep tty2 | grep -v grep
#
Killing the service on FC10 results in the service staying down, which is a serious regression. Granted, the version of Upstart in FC10 is 0.3.9, and the current release is 0.5.0. I don't know why FC10 has 0.3.9 when it was released in November and 0.5.0 has been out since August. Regardless, if you are running FC10 and expect respawned services to work as they have in the past, be prepared for a nasty surprise.
One of the nice features of using a supervising system is the restart of services in the event of crashes or unintended shutdowns. If you have ever remotely killed the parent sshd service on a remote system and then logged out, you will know what I mean.
FC10 does not take advantage of the supervisory features of Upstart beyond mingetty, which is a shame (assuming, of course, that it worked properly). With runit on Annvix, every system service that was daemonized was supervised, meaning a service could be killed or crash and within seconds it would be up again. This is a valuable feature to anyone working with remote systems or servers.
Down the road, it looks like Upstart will also handle time-based events, removing the need for cron, at, and similar scheduling systems. This would put it on par with OS X's launchd system, which can handle services and events. It looks as though future versions of Upstart could be quite useful, but as it stands now, in Fedora Core 10 at least, I would rather rely on runit for supervisory services.
Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years.
There are currently no comments for this post.