Introduction

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.

 

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.

 

Understanding upstart jobs and events

 

Jobs
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.

root@linuxnix:/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
respawn limit 10 5
umask 022

env SSH_SIGSTOP=1
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

 

Events
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

root@linuxnix:~# initctl list
avahi-daemon start/running, process 1049
mountnfs-bootclean.sh 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:

root@linuxnix:~# status cron
cron start/running, process 4984
root@linuxnix:~#

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

root@linuxnix:~# service cron status
cron start/running, process 4984

To stop a job, we use the stop command

root@linuxnix:~# stop cron
cron stop/waiting

To start a job, we use the start command

root@linuxnix:~# start cron
cron start/running, process 5028

Conclusion

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).

Post Views: 10,531
The following two tabs change content below.

Sahil Suri

He started his career in IT in 2011 as a system administrator. He has since worked with HP-UX, Solaris and Linux operating systems along with exposure to high availability and virtualization solutions. He has a keen interest in shell, Python and Perl scripting and is learning the ropes on AWS cloud, DevOps tools, and methodologies. He enjoys sharing the knowledge he's gained over the years with the rest of the community.