How Linux Used the Upstart Init System
This article examines Upstart, the event-driven init daemon developed by Canonical to replace the traditional System V init system in Linux distributions like Ubuntu. It outlines how Upstart handled system initialization through an asynchronous, event-based model, details the structure of its job configuration files, discusses its adoption across the broader Linux ecosystem, and explains the eventual transition to systemd.
What Was Upstart?
Upstart was an init system designed to manage the startup, maintenance, and shutdown of tasks and services during Linux operation. In Linux, the init system runs as Process ID 1 (PID 1), the direct or indirect ancestor of all other processes and the first user-space program executed by the kernel.
Canonical introduced Upstart in 2006, debuting in Ubuntu 6.10 (Edgy Eft). At the time, standard Linux distributions relied on the traditional UNIX System V (SysV) init model, which launched services sequentially according to predetermined runlevels. As modern computers introduced hot-pluggable devices (like USB drives, dynamically connected network interfaces, and external monitors), the rigid, sequential nature of SysV init became a bottleneck. Upstart was built to handle dynamic hardware changes efficiently and reduce system boot times.
The Event-Driven Architecture
Unlike SysV init's static process queues, Upstart functioned on an asynchronous, event-driven model:
- Events: Signals generated by the kernel, services,
or the system to indicate a state change (such as
starting,started,stopping,stopped, or specific hardware notifications likenet-device-up). - Jobs: Scripts or binaries managed by Upstart. Jobs defined which events triggered them and which events they emitted upon completion or failure.
- Asynchronous Execution: Because jobs responded to events rather than running in a strict sequential order, independent services could start concurrently. For instance, the system did not need to wait for a network connection to launch local services, significantly cutting boot times.
Upstart Job Configurations
Upstart eliminated complex, boilerplate shell scripts typical of
/etc/init.d/ in favor of declarative configuration files
located in /etc/init/ with a .conf
extension.
A standard Upstart configuration utilized specific stanzas to declare how a service should behave:
description "Example Network Service"
author "SysAdmin"
# Trigger events
start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [!2345]
# Process monitoring and lifecycle
respawn
respawn limit 10 5
# Execution
exec /usr/sbin/example-daemon --foreground
Key features of this configuration style included:
start onandstop on: Defined the logical conditions and events required to launch or terminate the service.respawn: Automatically restarted a process if it crashed unexpectedly, removing the need for third-party process monitors.exec/script: Simplified the direct invocation of the binary or allowed multiline shell blocks using thescriptstanza.
Administrators interacted with these jobs using utility commands such
as start <job>, stop <job>,
status <job>, and the master control tool
initctl.
Adoption Across the Linux Ecosystem
While created by Canonical specifically for Ubuntu, Upstart's performance improvements led to adoption by other major distributions:
- Ubuntu: Used as the default init system from Ubuntu 6.10 through Ubuntu 14.10.
- Red Hat Enterprise Linux (RHEL) and CentOS: Adopted Upstart in version 6, replacing the legacy SysV init, though implemented with compatibility layers to run older SysV scripts alongside native Upstart jobs.
- Fedora: Transitioned to Upstart in Fedora 9 before migrating to systemd in Fedora 15.
- Google ChromeOS: Leveraged Upstart for its lightweight nature and fast boot speeds to initialize user-space components and platform services.
The Transition to systemd
Despite its improvements over SysV init, Upstart faced criticism for tight coupling with Ubuntu development policies and its reliance on proprietary Canonical Contributor License Agreements (CLAs).
In the early 2010s, systemd emerged as an alternative that incorporated an event-driven architecture, declarative service management, socket activation, and deep cgroup integration. Following Debian’s technical committee vote in 2014 to adopt systemd as its default init system, Canonical announced that Ubuntu would follow Debian's lead. Ubuntu officially replaced Upstart with systemd in Ubuntu 15.04 (Vivid Vervet), marking the end of Upstart's widespread role in mainline Linux distribution architecture.