The upstart of Linux system

　　

Zi Gong asked for benevolence. Zi Yue: "工欲善其事, its prerequisite." The house is the state, the sage of his doctor, the benevolence of his friends. --Confucius (Spring and Autumn), "The Analects and Weiling"

"工欲善其事, its prerequisite"

Master a technology, know its development process is very important, know it, and then know the reason why. To be able to achieve and why the two know, need to understand the entire development process. As we did when we were young, we needed to understand the poet's writing background.

Cut into the topic, understand the development of the Linux system, since the thought can better understand the system, master the system.

　　Systemvinit--> upstart --> Systemd

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 machine , for example, when the USB drive is plugged into the interface, 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
• Dynamic start Service (PnP) 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.

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.job State Machine

There are four states that cause the INIT process to send a 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

is was 1 2, descriptiondescription "This job was only 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.

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 the existing mechanism works well, and in the graphical interface, things become 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.

The boot process for a traditional desktop session

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.

　　

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 |             : |             :::

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.

Reference

Http://www.ibm.com/developerworks/cn/linux/1407_liuming_init2/index.html

The upstart of Linux system