In our earlier articles, we’ve discussed the sysVinit and systemd service managers. In this article, we shift our focus to upstart and understand what is upstart and how it works. We’ll also discuss why OS distributions considered using upstart over init or a combination of upstart and init. Upstart was written by Scott James Remnant, a former employee of Canonical Ltd in 2006. It was started as an ambitious project as somewhat of a hybrid of SysVinit and Systemd. Upstart was originally developed for the Ubuntu distribution but is intended to be suitable for deployment in all Linux distributions as a replacement for the venerable System-V init. It was heavily adopted in Ubuntu and partially adopted in Centos 6 and RHEL 6. But it did not become very popular and all major enterprise distributions including Ubuntu shifted to systemd in their latest stable releases being Ubuntu 16.04 and RHEL/Centos 7.


What is upstart?
Like sysvinit and systemd upstart is a program that handles the system initialization process after the kernel is loaded. The system initialization is a critical part of operating system functionality is it controls the operation of every script and service. Upstart, like it’s counterparts manages services not only during system boot or shutdown but constitutes management of existing services while the system is running and also the addition or removal of services or scripts from the system initialization process. Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during the shutdown and supervising them while the system is running.

Related concept:   4 sleep command examples in Linux/Unix


Why use upstart over sysvinit?
The SysV boot process is strictly synchronous and serial in nature. This means that services get started or stopped one at a time, blocking future tasks until the current one has completed.  If anything in the boot process takes a long time, everything else has to wait.  Booting in a linear sequence also takes time, which is especially disadvantageous in a cloud-based environment where fast deployment is essential. Additionally, tasks only run when the init daemon changes state i.e. when the system transitions from one run level to another like a system shutdown or transitioning into single user mode.

Upstart is a new init daemon that allows services to be started in response to events rather than in bulk runlevels.
With each job file in the /etc/init directory being responsible for launching a service or for a specific component of system initialization.  There is no fixed sequence; instead, each job specifies the events to which it will react.
When an event occurs, Upstart starts all jobs that have been waiting for this event, in parallel.

Based on real-time events instead of a preset list of tasks in sequence, this replacement init daemon handles the starting and stopping of tasks and monitors these processes while the system is running. Upstart could support the most complex of systems and keep everything in check by using a structure of jobs.

The System V init daemon used changes in runlevels to determine when to start and stop processes. Ubuntu systems, which use the Upstart init daemon, have no concept of runlevels.  To ease migration from a runlevel-based system to an event-based system, and to provide compatibility with software intended for other distributions, Ubuntu emulates runlevels using Upstart.

Related concept:   How To See What Processes Are Running On Your System?


Understanding upstart jobs and events


In the world of Upstart, jobs are working processes, split into task jobs (with a purpose) and service jobs (which can run in the background).  A job is a series of instructions that init reads.  The instructions typically include a program and the name of an event.  The Upstart init daemon runs the program when the event is triggered.  You can run and stop a job manually using the initctl start and stop commands, respectively. Jobs are divided into tasks and services. A task is a job that performs its work and returns to a waiting state when it is done. A service is a job that does not normally terminate by itself. The init daemon monitors each service, restarting the service if it fails and killing the service when it is stopped manually or by an event. There are also abstract jobs – processes that run forever until stopped by a user with administrative privileges.

Given below is a sample job file for the ssh service on an Ubuntu 14.04 system.

[email protected]:/etc/init# cat ssh.conf
# ssh - OpenBSD Secure Shell server
# The OpenSSH server provides secure shell access to the system.
description"OpenSSH server"
start on runlevel [2345]
stop on runlevel [!2345]
respawn limit 10 5
umask 022
expect stop
# 'sshd -D' leaks stderr and confuses things in conjunction with 'console log'
console none
pre-start script
 test -x /usr/sbin/sshd || { stop; exit 0; }
 test -e /etc/ssh/sshd_not_to_be_run && { stop; exit 0; }
mkdir -p -m0755 /var/run/sshd
end script
# if you used to set SSHD_OPTS in /etc/default/ssh, you can change the
# 'exec' line here instead
exec /usr/sbin/sshd -D


Related concept:   7 Linux/Unix gzip and gunzip command examples

Events, however, are the signals used to trigger a certain action with a job or another event.  The common forms of events refer to the monitoring of a process: starting, started, stopping and stopped.


Working with upstart jobs
The initctl (init control) utility allows a system administrator working with root privileges to communicate with the Upstart init daemon.  Starting, stopping and reporting on jobs has fairly straightforward commands as we will see now. Let’s take a look at a few examples using an Ubuntu 14.04 system.

To list various upstart jobs and their state, we use the ‘initctl list’ command as shown below

[email protected]:~# initctl list
avahi-daemon start/running, process 1049 start/running
rsyslog start/running, process 970
tty4 start/running, process 1321
udev start/running, process 448
upstart-udev-bridge start/running, process 3839
avahi-cups-reload stop/waiting
mountall-net stop/waiting
passwd stop/waiting
startpar-bridge stop/waiting
ureadahead-other stop/waiting
---------output truncated for brevity

To view the status of a job, use the status command:

[email protected]:~# status cron
cron start/running, process 4984
[email protected]:~#

To be compatible with sysvinit, the service command still works.

[email protected]:~# service cron status
cron start/running, process 4984

To stop a job, we use the stop command

[email protected]:~# stop cron
cron stop/waiting

To start a job, we use the start command

[email protected]:~# start cron
cron start/running, process 5028


In this article, we discussed what is the upstart system initialization program and its potential benefits over the sysvinit system. We also showed you a couple of examples of managing services (upstart jobs).