Image of the glider from the Game of Life by John Conway
Skip to content

Why Upstart Is Good For Your Distro

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.

{ 12 } Comments

  1. Filip Andonov | February 8, 2008 at 8:05 am | Permalink

    Hi, Aaron! I am using UBUNTU 7.10 Gutsy Gibbon. Does this mean, that I am using Upstart? Because as far as I can see with PID 0 in my system is a process called init (/sbin/init). What should I do to use Upstart?

  2. Aaron | February 8, 2008 at 8:22 am | Permalink

    @Filip Andonov- Even though Ubuntu uses Upstart, remember, that it's 100% backwards compatible with SysVinit. As such, "init" will be the first process on your system. /sbin/init is managed now by Upstart, rather than SysVinit.

  3. Tom Vollerthun | February 8, 2008 at 9:52 am | Permalink

    The thing that is still sorely missing is: boot-stuff that actually uses upstart. Despite the fact that no packages without upstart-support should be included into Ubuntu (version?), the /etc/event.d does not contain anything new.
    As long as upstart uses the same scripts as SysV-Init does, it behaves the same, right? So after 18 months there is still _no_ advantage in using upstart, which really is a pity.
    When will the cool boot-goodness actually be put to use?

  4. Mike | February 8, 2008 at 10:10 am | Permalink

    Interesting article. One correction: the PID of init is not "typically" 1--rather the PID of init *must* be 1. This is hard-coded into the OS in all kinds of places (in Linux, and probably in other Unixes, too).

  5. Matthew Nuzum | February 8, 2008 at 10:23 am | Permalink

    Hi Aaron, last fall I got to listen in on Scott's presentation about the test framework he built for upstart's development. He said he's got tests that cover 97% of the code and the tests compromise more lines of code than upstart does. (iirc) The only reason it wasn't 100% was that because of the nature of upstart being init and running as pid 1 there are some things that were just not testable. This attention to detail and commitment to quality code shows because as of the time of his presentation the defect rate for upstart was phenomenally low (at that time only 1 defect reported).

    I found it quite inspiring.

  6. Tom Mann | February 8, 2008 at 11:56 am | Permalink

    In the list of scenarios there are a lot of (edgy+1) comments - on a side note is there any way of knowing which of these were implemented in feisty?

    Upstart is rocking on!

  7. Christopher Giroir | February 8, 2008 at 9:25 pm | Permalink

    Has upstart gotten any better since Feisty? We run some Feisty servers at work and actually had some trouble creating our own jobs. It seemed sometimes upstart would loop a lot trying to start a process, fail and then stop trying. Running the commands manually of course worked. So anyway, long story short we aren't using it for these trouble processes and never could figure out what was going on.

    The Documentation seemed non-existent on some features of upstart. It annoyed me that Ubuntu server installs used a system where I pulled some of job syntax from the source code.

    Anyway I hope it has matured a bit since these Feisty installs, looking forward to updating to Hardy.

  8. Omari | February 10, 2008 at 6:10 pm | Permalink

    Just wanted to echo Tom Vollerthun...Upstart sounded interesting, but here it is over a year later and Ubuntu makes no use of the allegedly cool features...I poked around in the appropriate /etc directories and all I could find is stuff that invokes the old Sys V init scripts.

  9. Will It Work | February 11, 2008 at 6:42 am | Permalink

    My only thing is what about the softwares that use SYSV system calls? Specifically, I was thinking of Apache here.

  10. Jeremiah Roth | February 16, 2008 at 9:00 pm | Permalink

    When I first heard of Upstart I was thrilled because I'm a big fan of OS X's launchd. Having an event driven system gives you so much more freedom, and it's something I sorely miss when working on Linux (RHEL). Thanks for the scenarios you listed - it's sometimes difficult for me to explain the coolness factor of it to someone.

  11. Mark | June 22, 2011 at 10:57 am | Permalink

    Upstart is the worst implementation of all time, please do what you can to convince distros to stop using it.

    At least until all of the problems where a system stops booting with no messages and no way to write upstart debug messages to a log file.

  12. Aaron | June 22, 2011 at 12:14 pm | Permalink

    You're going to have do better than that, than just saying "[it] is the worst implementation of all time" to convince other operating systems from using it. Upstart has proven itself as a very capable event-driven init system. Further, if you don't like the fact that you can't see the messages of the boot process, you can disable the GUI by configuring or removing usplash.

{ 2 } Trackbacks

  1. [...] che “Fedora 9 tenta di adottare Upstart di Ubuntu“, ho appena letto un articolo di Aaron Toponce che capita quasi a fagiuolo1 e quindi non posso non proporne la [...]

  2. [...] Read the rest of this great post here [...]

Post a Comment

Your email is never published nor shared.