Aaron Toponce

Disclaimer: I don't know enough about Upstart to hold a low-level conversation about it. What I do know of Upstart is what I have read on the Ubuntu wiki, the Upstart FAQ and a few docs scattered here and there around the web. If I have misrepresented Upstart, its goals or intentions, or SysVinit for that matter, please email me and let me know. Thanks.

I recently discovered that Fedora 9 will be replacing SysVinit with Upstart. To me, this is good news. To others, maybe not so much. So, the question you may be asking is, what is SysVinit and what is upstart?

First, a little background. SysVinit, pronounced "System 5 init" or "Sys 5 init" or just "init" is a the first daemon that runs on a Unix or Linux system. As such, it typically has the PID of 1. Also, every other process also running on the box is a child process of init. What does this mean? It means that if you stop init, you will effectively stop every process on your box, basically inappropriately shutting down.

For many years, SysVinit has been the defacto in managing processes on your box. Not only processes, but also the order of booting and maintaining run levels, among other things. Because it has existed for so long, certainly there is no need to replace it. I mean, if there were issues with SysVinit, we would have discovered them by now, right? One would think.

Actually, developers the world over have noticed the shortcomings of SysVinit, and have made replacements, some of which are already deployed. Common ones include:

• initng- an init replacement designed to speed up boot by starting processes asynchronously.
• eINIT- similar to initng, but removing the need for shell scripts.
• Upstart- also similar to initng, but event driven. Developed by Scott Remnant, and used in Ubuntu.
• launchd- an init replacement designed by Apple found in Mac OS X.
• Service Management Utility- an init replacement developed my Sun and used since Solaris 10

So, why the need to replace SysVinit? Let's look over some common scenarios, and see where SysVinit falls short. All of these scenarios can be found on the Replacementinit page of the Ubuntu wiki:

• Jean is a power user who wishes to use a USB disk for part of her filesystem. This currently frequently fails because the USB disk sometimes takes longer to initialize than the boot process takes to get to the point where it mounts the filesystem. She would rather the boot process was robust, and the disk was mounted when initialized.
• Corey is the administrator of a number of servers, and has problems with certain daemons that frequently crash. He would prefer the daemons to be automatically restarted if this happens, to avoid loss of service.
• iPod in, and remember to stop it afterwards. She would rather the system started and stopped the software automatically based on the presence of her iPod. (maybe edgy+1)
• Ethan is a software developer. He has a script that he wishes to run hourly, provided that the script is not still running from before. He would rather the task scheduler could take care of that for him, than have to reinvent a lock around the task. (edgy+1)
• Katie is a database administrator. She wishes the database to be automatically backed up whenever the server is shutdown, whether for upgrade or system reboot. There is currently no way for her to set a task to be run when a service is stopped.
• Justin is an ordinary user with a low-end system. He would rather services and hardware handlers were started only when needed, rather than on all systems.
• Carla is a system administrator. She needs to be able to tell which services failed to start on boot, examine why, and see which services are currently running.
• Thomas is a system administrator. He frequently gets frustrated that there is no consistency to how tasks are added to the system. A script to perform a task at shutdown must be written and activated completely differently to one performed when the system is started. (edgy+1)
• Marie is a security consultant. She has discovered several problems with processes that run task scripts not providing a consistent environment, including potential problems such as leaving file descriptors open. (edgy+1)
• Hugo is an ordinary user and has to frequently reboot his computer. He would prefer that shutting down and booting up took as little time as possible.
• Helen is an experienced UNIX user, with multiple years of experience. She does not wish to have to relearn that which she has learned already, and would rather continue using the tools that she is used to and only learn the newer ones when necessary.
• Matthieu is a distribution developer who maintains several packages that provide services or perform tasks. He does not want to have to update his packages until he is ready to take advantage of new features or abilities, his existing scripts should continue to work unmodified in their original locations.

If you read through that list, hopefully you can see where SysVinit falls short. Because of the dynamic nature of removable hardware, and a very robust kernel, SysVinit no longer meets the needs of our users. We need something more. Something that will speed up the boot process. Something that will launch processes based on events. Thus, the reason for Upstart.

The idea of an event driven system is nothing new. Crond, atd and inetd are all event driven tools that we've used on Unix and Linux for years. So, why not start jobs based on listening events, such as plugging in a USB disk, mounting /usr when needed and unmounting when not needed, etc? This is the design of Upstart.

First off, Upstart is 100% backwards compatible with SysVinit scripts. All of your /etc/init.d/ goodness is still available. We want to meet those use cases listed above, without modifying existing init scripts. Further, because Upstart is event driven, we can also replace crond, atd and inetd, while still maintaining backwards compatibility.

Ubuntu has been using Upstart since their 6.10 release. Nearly 18 months later, the reception of Upstart has been largely positive to the point that the Fedora Project is replacing init with Upstart in their Fedora 9 release. This also means it's very likely that we'll see it filter it's way to RHEL 6, which means CentOS and even OEL. Other Linux and Unix variants are also encouraged to drop the aging SysVinit with Upstart.

It just makes sense.