Brief analysis of Linux initialization init system, part 2nd: Upstart

From Sysvinit to Systemd

In recent years, the Linux system init process has undergone two major evolution, the traditional sysvinit has faded out of the historical stage, the new system upstart and SYSTEMD each have the characteristics, but more and more Linux distribution adopted systemd. This article briefly describes the use and rationale of these three init systems, which each Linux system administrator and system software developer should know to better manage systems and develop applications. This article is the second part of the series, mainly on the characteristics and use of upstart.

Upstart Introduction

If your Linux distribution is Ubuntu, you may find that you can't find the/etc/inittab file on your computer because Ubuntu uses a new init system called upstart.

The reason for developing upstart

About 2006 years or earlier, Ubuntu developers tried to install Linux on laptops. During this time the technician found some problems with the classic sysvinit: it was not suitable for notebook environments. This prompted the programmer Scott James remnant to start developing upstart.

When the Linux kernel enters the 2.6 era, there are many new updates to the kernel features. The new feature makes Linux a great server operating system, and can be used for desktop and even embedded devices. One feature of desktop or portable devices is frequent reboots, and frequent use of hardware hot-swap technology. In the modern computer system, the hardware is many, the interface is limited, people not all devices are always connected to the computer, for example, the USB stick is not connected to the computer, the use of plug into the USB jack. Therefore, some peripherals may not be connected when the system is power-up. Instead, connect the devices as needed when they are started. With the support of the 2.6 kernel, once the new peripherals are connected to the system, the kernel can automatically discover them in real time and initialize the devices to use them. This provides a lot of flexibility for portable device users.

But these features pose some challenges for sysvinit. When the system is initialized, the device that needs to be initialized is not connected to the system, such as a printer. To manage print tasks, the system needs to start services such as CUPS, and if the printer does not have access to the system, starting these services is a waste. Sysvinit has no way of dealing with this kind of demand, it must start all possible services at once, and even if the printer is not connected to the system, the CUPS service must start up.

There is also a problem with the mounting of the network share disk. In/etc/fstab, you can specify that the system automatically mounts a network disk, such as NFS, or iSCSI devices. As you can see in the first section of this article Sysvinit, sysvinit analysis/etc/fstab mount the file system This step is before the network starts. However, if the network does not start, NFS or ISCSI are inaccessible and, of course, cannot be mounted. Sysvinit uses netdev approach to solve this problem, that is,/etc/fstab found the Netdev attribute mount point, do not attempt to mount it, after the network initialization and enable, there is a dedicated NETFS service to mount all these network disks. This is a last resort remedy, which brings inconvenience to the administrator. Some novice administrators have never even heard of the Netdev option, so they often become a trap for system management.

In response to all of the above, the Ubuntu developer, after evaluating several of the optional INIT systems at the time, decided to redesign and develop a new init system, the upstart. Upstart based on the event mechanism, for example, when the USB drive is plugged in, Udev gets the kernel notification and discovers the device, which is a new event. Upstart triggers an appropriate wait task after sensing the event, such as handling a mount point that exists in the/etc/fstab. With this event-driven pattern, upstart perfectly solves the new problems posed by Plug and Play devices.

In addition, the adoption of event-driven mechanisms has led to some other beneficial changes, such as faster system startup time. The Sysvinit runtime is synchronously blocked. When a script runs, subsequent scripts must wait. This means that all initialization steps are executed serially, but many services are not related to each other and can be started in parallel, thereby reducing the startup time of the system. When Linux is used in a large number of servers, the system startup time may not be as important, but for desktop and portable devices, the length of the boot time can have a significant impact on the user experience. In addition, new Server-side technologies such as cloud computing often require a single device to be able to start more quickly.

Upstart meet these needs, not only the desktop system Ubuntu has adopted the upstart, even enterprise-Class Server-level RHEL also defaults to upstart to replace Sysvinit as the init system.

Features of upstart

Upstart solves the shortcomings of the previously mentioned sysvinit. With the event-driven model, upstart can:

• Start the system faster
• Dynamically start services when new hardware is discovered
• Dynamic stop service when hardware is removed

These features enable the upstart to be used in desktop or portable systems to handle the dynamic hardware plug-and-pull characteristics of these systems.

Back to top of page

Upstart Concepts and terminology

Upstart's basic concepts and design are clear and clear. The main concept of upstart is job and event. A job is a unit of work that is used to complete a work, such as starting a background service or running a configuration command. Each job waits for one or more events, and once the event occurs, upstart triggers the job to complete the work.

Job

A job is a unit of work, a task, or a service. Can be understood as a service script in Sysvinit. There are three types of jobs:

• Task job;
• Service job;
• Abstract job;

A task job represents tasks that are completed within a certain amount of time, such as deleting a file;

The service job represents a background service process, such as Apache httpd. The process generally does not exit, once started to become a background daemon process, managed by the Init process, if such a process exits, restarted by the Init process, they can only be signaled by the INIT process to stop. Their stops are usually triggered by the stop events they rely on, but upstart also provides command-line tools to let managers manually stop a service;

The Abstract job is only used internally by upstart and is only helpful for understanding the internal mechanisms of upstart. We don't have to care about it.

In addition to the above classification, there is another job classification method. Upstart can be used not only for the initialization of the entire system, but also for the initialization of each user session. The initialization task of the system is called the systems job, for example, the task of mounting the file system is a system job, and the initialization service of the user session is called the session job.

Job life cycle

Upstart maintains a life cycle for every job. In general, work has to start, run, and end these kinds of States. To more precisely describe the changes in the work, upstart also introduces some other states. For example, the beginning of the beginning (Pre-start), is about to start (starting) and has started (started) several different states, so that you can more accurately describe the current state of the work.

Work begins in some initial state, changes gradually, perhaps through several different states, eventually entering another state, forming a state machine. During this process, the INIT process emits the appropriate event when the state of the work is about to change.

Possible status of Job in table 1.Upstart

Status Name	meaning
Waiting	Initial state
Starting	Job is about to start
Pre-start	Execute the pre-start segment, the work that should be done before the task begins
Spawned	Prepare to execute script or exec segment
Post-start	Perform post-start actions
Running	Interim state set after Post-start section processed denoting job was running (but it could have no associated pid!)
Pre-stop	Execute Pre-stop Segment
Stopping	Interim state set after Pre-stop section processed
Killed	The task is about to be stopped
Post-stop	Execute Post-stop Segment

Figure 1 shows the state machine for the Job.

Figure 1. Job ' s life cycle

Four of these states cause the INIT process to send the corresponding event, indicating the corresponding change in the work:

• Starting
• Started
• Stopping
• Stopped

Other state changes do not emit an event. So let's take a look at the detailed meaning of the event next.

Events Event

As the name implies, an event is one. The event exists in upstart as a notification message. Once an event has occurred, upstart sends a message to the entire system. There is no means to prevent an event message from being known by other parts of the upstart, that is, all work and other events in the entire upstart system will be notified once the event occurs.

The Event can be divided into three categories: Signal,methods or hooks.

Signals

The Signal event is non-blocking, asynchronous. Control immediately returns after sending a signal.

Methods

The Methods event is blocked and synchronized.

Hooks

The Hooks event is blocked and synchronized. It is between signals and Methods, and the process that invokes the Hooks event must wait for the event to complete before it can gain control, but does not check whether the event was successful.

The event is a very abstract concept, and below I'm listing some common events that I hope will help you learn more about what the event means:

• The init process sends a "START" event when the system is power-up
• When the root filesystem is writable, the corresponding job sends file system-ready events
• A block device is discovered and initialized to complete, sending the corresponding event
• A file system is mounted and the corresponding event is sent
• Similar to ATD and Cron, you can send events at a point in time, or at a point in a cycle
• When another job starts or ends, the corresponding event is sent
• When a disk file is modified, the corresponding event can be emitted
• When a network device is discovered, a corresponding event can be issued.
• A corresponding event can be emitted when the default route is added or deleted

Different Linux distributions have different customizations and implementations for upstart, and the events implemented and supported vary, and can be used man 7 upstart-events to view the list of events.

Collaboration between Job and Event

Upstart is a system that is triggered by an event to run, and each program's operation is triggered by the events it relies on.

The process of initializing the system is done in collaboration with the work and events, which can be described as follows: When the INIT process starts running when the system is initialized, the INIT process itself issues different events, and these initial events trigger some work to run. Different events are released during each work run, and these events will trigger new work runs. So again and again until the entire system is functioning properly.

What events will trigger the operation of a job? This is defined by the work configuration file.

Work profile

Any job is defined by a work profile (Job configuration file). This file is a text file that contains one or more subsections (stanza). Each section is a complete definition module that defines one aspect of the work, such as the author section defines the author of the work. The work profile is stored under/etc/init and is a file with. conf as the file suffix.

Listing 1. One of the simplest work profiles

#This is a simple demo of Job Configure file#this-Comment, start with # #Stanza 1, the Authorauthor "Liu Ming" #Stan Za 2, descriptiondescription "This job is only have author and description, so no use, just a demo"

The above example does not have any effect, and a real work profile will contain many sections, the more important of which are the following:

"Expect" Stanza

Upstart in addition to the system startup process, upstart offers a range of management tools as well as sysvinit. When the system starts, the administrator may also need to perform maintenance and tuning, such as starting or stopping a system service. or switch the system to another working state, such as changing the operating level. The use of upstart management tools is described in detail later in this article.

To start, stop, restart, and query for a system service. Upstart needs to track the processes that the service corresponds to. For example, the HTTPD service has a process PID of 1000. When the user needs to query whether the HTTPD service is working properly, upstart can use the PS command to query the process 1000, if it is still working properly, it indicates that the service is normal. When the user needs to stop the HTTPD service, upstart uses the KILL command to terminate the process. To do this, upstart must track the process number of the process.

Part of the service process takes two derived (fork) techniques to turn itself into a daemon process (daemon), while others do not. If a service derives two times, the upstart must use the second derived process number as the PID of the service. However, upstart itself cannot determine whether the service process will derive two times, so you must specify the expect section in the work configuration file that defines the service to tell upstart whether the process will derive two times.

There are two types of Expect, "Expect fork" means that the process will only fork once; "Expect daemonize" means the process will fork two times.

"Exec" Stanza and "script" Stanza

A upstart job must be done, either by running a shell command or by running a script. Use the "EXEC" keyword to configure the commands that you want to run, and use the "script" keyword to define the scripts that need to be run.

Listing 2 shows the use of exec and script:

Listing 2.script Examples

# mountall.confdescription "Mount filesystems on Boot" start on Startupstop on starting Rcs...script  ./ETC/DEFAULT/RC S  [-f/forcefsck] && force_fsck= "--force-fsck"  ["$FSCKFIX" = "yes"] && fsck_fix= "--fsck-fix"    c4/> ... EXEC mountall–daemon $force _fsck $fsck _fixend script ...

This is an example of Mountall, which runs at system startup and is responsible for mounting all file systems. This work requires a complex script that is defined by the "script" keyword, and exec is used in the script to execute the mountall command.

"Start on" Stanza and "stop on" Stanza

"Start on" defines all the events that trigger the work. The syntax for "start on" is simple, as follows:

Start on EVENT [[Key=]value] ... [And|or ...]

The event represents the name of the incident, and multiple events can be specified in start on, indicating that the start of the work depends on the occurrence of multiple events. Multiple events can be combined with and OR OR, "means that all must happen" or "one of them occurs", and so on. In addition to the event, the start of the work can depend on certain conditions, so after the event of start on, you can use Key=value to represent additional conditions, which are generally compared to an environment variable (KEY) and a specific value (value). If there is only one variable, or if the order of the variables is known, KEY can be omitted.

"Stop on" and "start on" are very similar, except that you define where the work needs to stop.

Code Listing 3 is an example of "Start on" and "Stop on".

Listing 3. Start On/stop on Example

#dbus. Confdescription     "d-bus system Message Bus" Start on Local-filesystemsstop on deconfiguring-networking ...

D-bus is a system message service with a configuration file indicating that D-bus is started when the system issues a Local-filesystems event, and when the system issues a deconfiguring-networking event, stop the D-bus service.

Session Init

Upstart can also be used to manage initialization of user sessions. As I write this article today, most Linux distributions have not yet used the upstart management session. Only in Ubuntu Raring version, use upstart to manage the initialization of user sessions.

First let's look at the concept of the Session. Sessions are a user session where users log on from a remote or local login system until the user exits. This entire process constitutes a conversation.

Each user's usage habits and usage are different, so users often need to customize their sessions, such as adding specific command aliases, launching special applications or services, and so on. These tasks are initialized to a specific session and can therefore be referred to as session Init.

There are two modes for users to use Linux: Character mode and graphical interface. In character mode, session initialization is relatively straightforward. Only one shell can be started after the user logs on, using the system through the shell command. Various shell programs support a startup script that runs automatically, such as ~/.BASHRC. Users include custom commands that need to be run in these scripts. Character session requirements are simple, so this existing mechanism works well.

Under the graphical interface, things get a little more complicated. When a user logs in, they see not a shell prompt, but a desktop. A complete desktop environment is made up of many components.

A desktop environment includes window Manager,panel and some other basic components defined under/usr/share/gnome-session/sessions/, plus some ancillary applications that help form a complete and convenient desktop, such as System Monitors,panel applets,networkmanager,bluetooth,printers and so on. When a user logs in, these components need to be initialized, which is much more complex than the character interface. The current work of starting various graphical components and applications is done by Gnome-session. The process is as follows:

In Ubuntu, for example, when a user logs in to the Ubuntu GUI, the display manager LightDM starts xsession. Xsession then starts the gnome-session,gnome-session responsible for the other initialization work, then starts a desktop session.

Figure 2: The traditional desktop session startup process

init |-LIGHTDM |   | -Xorg |   | -LIGHTDM---session-child |        | -Gnome-session--session=ubuntu |             | -Compiz |             | -Gwibber |             | -Nautilus |             | -Nm-applet |             : |             : | |-Dbus-daemon--session |::

This process has some drawbacks (similar to sysvinit). Some applications and components do not actually need to be started during session initialization, and a better choice is to start when they are needed. For example, the Update-notifier service, which continuously monitors several file system paths, alerts users once they find a package that can be updated. These file system paths include the newly inserted DVD disk, and so on. Update-notifier is started and run by Gnome-session, and in most cases the user does not insert a new DVD, and the Update-notifier service runs in the background and consumes system resources. The better mode is to run Update-notifier when the user inserts the DVD. This can speed up startup time and reduce the overhead of system resources such as memory during system operation. For mobile, embedded devices, etc. this also means power saving. In addition to the Update-notifier service, there are other similar services. For example, network manager, where users rarely switch devices within a day, most of the time the Net Manager service is simply a waste of system resources, such as backup Manager and other resident memory, and the service is rarely used in the background without interruption.

Using Upstart's event-based on-demand mode can be a good solution to these problems, such as when a user plugs into a network cable, as the user inserts a cable to indicate the need to use the net, which can be called on-demand startup.

Describes the session initialization process after using upstart.

Figure 3: The Desktop session init process using upstart

init |-LIGHTDM |   | -Xorg |   | -LIGHTDM---session-child |        | -Session-init # <--upstart running as normal user |             | -Dbus-daemon--session |             | -Gnome-session--session=ubuntu |             | -Compiz |             | -Gwibber |             | -Nautilus |             | -Nm-applet |             : |             :::

Back to top of page

Upstart use

There are two types of people who need to understand the use of upstart. The first category is system developers, such as MySQL developers. They need to know how to write work profiles to use upstart to manage services. For example, start and stop the MySQL service.

Another situation is system administrators, who need to master upstart management commands in order to configure and manage system initialization and manage system services.

Upstart knowledge that system developers need to know

System developers not only need to master the writing of the work profile, but also need to know some programming requirements for the service process. This article lists only the syntax for a few work profiles. To fully master the work profile, you need to read Upstart's manual in detail. Here's a look at how to use upstart to implement a traditional runlevel, and then learn how to flexibly work with working profiles.

Upstart operating level in the system

Upstart's operations are entirely based on work and events. Changes in the state of the work and operations can cause events that trigger other work and events.

The traditional Linux system initialization is based on the runlevel, i.e. Sysvinit. For historical reasons, most of the software on Linux still uses the traditional Sysvinit script startup method, and does not develop a new startup script for Upstart, so even on Debian and Ubuntu systems, it is necessary to emulate the old Sysvinit's runlevel mode in order to Most existing software is compatible.

Although upstart itself does not have a concept of runlevel, it can be simulated with upstart's work. Let's take a complete look at the system startup process under the upstart mechanism.

System Boot Process

Describes the start-up process for upstart.

Figure 4.UpStart Startup process

The system is power-up and runs GRUB loaded into the kernel. The kernel performs hardware initialization and the kernel itself initializes. At the end of kernel initialization, the kernel will start the init process with PID 1, which is the upstart process.

The upstart process immediately issues a "startup" event after performing some of its own initialization work. In the red box with a red arrow to indicate the event, you can see the "Startup" event at the top left.

All work that relies on the "startup" event is triggered, the most important of which is mountall. The Mountall task is responsible for mounting the file system that is needed in the system, and when the work is done, the Mountall task issues the following event: Local-filesystem,virtual-filesystem,all-swaps,

Where the Virtual-filesystem event triggers the Udev task to start working. Task Udev triggers the work of Upstart-udev-bridge. The Upstart-udev-bridge will issue a net-device-up Iface=lo event, indicating that the local loopback IP network is ready. At the same time, the task Mountall continues to execute, eventually issuing the filesystem event.

At this point, the task Rc-sysinit is triggered because the rc-sysinit start on condition is as follows:

Start on filesystem and net-device-up Iface=lo

Task Rc-sysinit calls Telinit. The Telinit task emits a runlevel event that triggers execution/etc/init/rc.conf.

Rc.conf executes all the scripts under the/etc/rc$.d/directory, and Sysvinit is very similar, and the reader can refer to the first part of this article for a description.

Things to note when developing a program

As a program developer, when writing system services, you need to understand some of the special requirements of upstart. Only software that complies with these requirements can be managed by upstart.

Rule one, the number of derivations to be declared.

Many Linux back-office services have turned themselves into a background service program by deriving two of times of skill. If you write a service that also uses this technique, you must explicitly let upstart's maintainers know this through documentation or some other way, which will affect upstart's expect stanza, which we have described in detail earlier in this stanza.

Rule two, which can be used after derivation.

The daemon must ensure that the service is available when it completes the second derivation. Because upstart determines whether a service is in a ready state by deriving a count.

Rule three, comply with the requirements of SIGHUP.

Upstart will send the SIGHUP signal to the sprite process, at this point, upstart want the sprite process to do the following response work:

• Complete all necessary reinitialization tasks, such as re-reading the configuration file. This is because upstart's command "Initctl Reload" is designed to allow the service to update the configuration without rebooting.

• The sprite process must continue to use the existing PID, which means that fork cannot be called when SIGHUP is received. If the service must call fork here, it is equivalent to deriving two times, referring to the handling of rule one above. This rule ensures that upstart can continue to use the PID to manage the service.

Rule four, receive sigtem that is shutdown.

• When the SIGTERM signal is received, upstart expects the daemon process to exit cleanly immediately, releasing all resources. If a process does not exit after receiving the SIGTERM signal, upstart will send a SIGKILL signal to it.

Upstart commands that system administrators need to know

As a system administrator, an important responsibility is to manage system services. such as system services monitoring, start, stop and configuration. Upstart provides a series of commands to accomplish these tasks. The core of this is initctl, a command-line tool that has a ribbon command style.

For example, you can use the Initctl list to see an overview of all the work:

$initctl Listalsa-mixer-save Stop/waitingavahi-daemon start/running, process 690mountall-net STOP/WAITINGRC stop/ Waitingrsyslog start/running, Process 482screen-cleanup stop/waitingtty4 start/running, process 859udev start/running, Process 334upstart-udev-bridge start/running, process 304ureadahead-other stop/waiting

This is the output on the Ubuntu10.10 system, and the output on the other Linux distributions will be different. The first column is the job name, such as Rsyslog. The second column is the goal of the work, and the third column is the state of the work.

You can also use Initctl stop to stop a running job; start a job with Initctl, or you can use INITCTL status to see the status of a job; initctl restart restart a job; Initctl Reloa D You can have a running service reload the configuration file. These commands are very similar to traditional service commands.

Table 2.service Command and Initctl command comparison

Service Command	Upstart initctl Command
Service start	Initctl start
Service Stop	Initctl stop
Service restart	Initctl restart
Service Reload	Initctl Reload

In many cases the administrator does not like the subcommand style because there are too many characters to be typed manually. Upstart also provides shortcut commands to simplify initctl, which in effect simply invoke the corresponding INITCTL commands internally. Like Reload,restart,start,stop and so on. Starting a service allows you to simply call

Start <job>

This is the same effect as performing initctl start <job>.

Some commands are intended to be compatible with other systems (primarily sysvinit), such as displaying runlevel with/sbin/runlevel commands:

$runlevelN 2

This output indicates that the current system has a running level of 2. And the system does not have a previous runlevel, which means that the operating level has not been modified after the system has been booted into a predetermined runlevel.

So how do you change the default operating level after the system is power-up?

In the upstart system, you need to modify the Default_runlevel parameter in the/etc/init/rc-sysinti.conf to modify the default startup RunLevel. This is different from the habit of sysvinit, and we need to pay extra attention.

There are also a few gadgets released with upstart to help develop upstart or diagnose upstart problems. Like Init-checkconf and Upstart-monitor.

You can also use the Initctl emit command to send an event from the command line.

#initctl Emit <event>

This is generally used to upstart the error itself.

Back to top of page

Upstart summary

As you can see, upstart's design is more advanced than sysvinit. Sysvinit is no longer used on most Linux distributions, and some distributions use upstart, such as Ubuntu, while others, such as Fedora, use an init system called SYSTEMD. Systemd appeared later than upstart, but developed rapidly, although upstart is also actively developed and more and more applications, but SYSTEMD seems to develop faster, I will introduce Systemd in the next article.

Brief analysis of Linux initialization init system, part 2nd: Upstart (RPM)