Problem solve Get help with specific problems with your technologies, process and projects.

System V init's successor, Linux Upstart, isn't tough to master

Used to System V init from previous Linux distributions? Never fear. Here are a few tips to get started with its successor, Linux Upstart.

Much work has been done recently on the way that Linux boots. After having used System V init for years, Upstart seemed a worthy successor. The first distributions have only just begun to use Upstart as their default boot solution, and a new method named System is conquering the world. System will absolutely be the standard on most if not all Linux distributions that will be released in the next months and years, but in the meantime, as an administrator you still have to deal with upstart.

Because currently Red Hat is the most important Linux distribution that relies on Upstart, the information in this article is based on Red Hat Enterprise Linux 6.3. Names of files may be different if you're using a different distribution.

The most important design goal that the developers had in mind when developing Upstart was speed. The old method started services sequentially, and that took a lot of time. As an alternative, Upstart uses an event-driven approach. In this approach, the Upstart process -- which is implemented by the /sbin/init daemon -- is the first thing that is started when the Linux kernel boots. After starting, it executes a few scripts that take care of starting all the processes your server needs. These scripts are in the /etc/init directory. The old /etc/inittab file, which took care of starting services sequentially in System V init, isn't relevant anymore. The only thing it is still used for is to specify the default runlevel that should be started. What is also useful is that the old file contains a lot of comments that explain which Upstart file has which function in the current configuration (see Listing 1).

Listing 1: Check /etc/inittab if you want to know which Upstart configuration file is used to do what
[root@hnl ~]# cat /etc/inittab
# inittab is only used by upstart for the default runlevel.
# System initialization is started by /etc/init/rcS.conf
# Individual runlevels are started by /etc/init/rc.conf
# Ctrl-Alt-Delete is handled by /etc/init/control-alt-delete.conf
# Terminal gettys are handled by /etc/init/tty.conf and /etc/init/serial.conf,
# with configuration in /etc/sysconfig/init.
# For information on how to write upstart event handlers, or how
# upstart works, see init(5), init(8), and initctl(8).
# Default runlevel. The runlevels used are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)

As mentioned, everything that was started from /etc/inittab in the past is now in different configuration files in the /etc/init directory. Of these, two are particularly important in the boot procedure. The /etc/init/rcS.conf file is used for system initialization, and the /etc/init/rc.conf file is used to start the runlevel services. Examining these scripts reveals that Red Hat hasn't changed that much. The most important line in /etc/init/rcS.conf is the line that starts rc.sysinit, a script that takes care of starting everything your server needs to do its work, like mounting file systems and initializing proc and swap.

The other script is /etc/init/rc.conf, which takes care of starting services in the runlevels. Upstart on RHEL 6 is still fully compliant with runlevels as they were used in the old days of System V init. The scripts that start the services themselves are in the directory /etc/init.d. These are the scripts that you can start with a command-like service nameofthescript start.

Related story

What Linux admins should know about RHEL's switch to Upstart

To automate the start of these scripts, during the boot procedure, Upstart executes symbolic links that start with S in the directory /etc/rcX.d, where X is the current runlevel to be started. So if your server is configured to start runlevel 3, from the /etc/init/rc.conf file the rc script is started and it executes all symbolic links in order. On my system that means that /etc/rc3.d/S01sysstat is the first thing that is executed, and /etc/rc3.d/S99local is the last script that is executed.

At the end of the procedure, all services that are configured to be started are started by using this approach. As an administrator, you can still use the chkconfig command to put the services in the runlevels where they are typically needed.

After processing the runlevels, a few minor scripts are executed. These are, for instance, the /etc/init/start-ttys.conf script, which prepares all TTYs on your server, or prefdm.conf, which runs the graphical interface in case you use it. As an administrator, it is interesting to know these scripts exist, but you'll never really change anything in them.

If you've worked with System V init in previous versions of Linux, you won't have a hard time managing Upstart in Red Hat Enterprise Linux 6. Many things didn't change at all, and that includes the way an administrator manages Upstart. As an administrator, you'll still use commands like chkconfig to enable services, and there still are runlevels. The most important change is in the way the configuration files are organized. Instead of using one file that is executed sequentially, you'll now deal with a couple of configuration files in the /etc/init directory.

Now you know which are the most important of these configuration files, and that can be useful to know if you ever need to troubleshoot your server.

ABOUT THE AUTHOR: Sander van Vugt is an independent trainer and consultant based in the Netherlands. He is an expert in Linux high availability, virtualization and performance, and has completed several projects that implement all three. He is also the writer of various Linux-related books, such as Beginning the Linux Command Line, Beginning Ubuntu Server Administration and Pro Ubuntu Server Administration.

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.