Analysis of Linux init system initialization, Part 1: UpStart

Analysis of Linux init system initialization, Part 1: UpStart
Upstart Introduction

If the Linux release version you are using is Ubuntu, you may find that the/etc/inittab file cannot be found on your computer, this is because Ubuntu uses a new init system called upstart.

Related Articles:

1. Analysis of Linux init system initialization, Part 1: sysvinit
2. Analysis of Linux init system initialization, Part 1: UpStart
3. Analysis of Linux init system initialization, Part 1: Systemd

Reasons for Upstart Development

Around 2006 or earlier, Ubuntu developers tried to install Linux on a laptop. During this period, technicians found that the classic sysvinit had some problems: it was not suitable for the notebook environment. This prompted programmer Scott James Remnant to start upstart development.

When the Linux kernel entered the 2.6 era, many new kernel functions were updated. The new features make Linux not only an excellent server operating system, but also can be used for desktop systems and even embedded devices. One feature of desktop systems or portable devices is frequent restart and frequent use of hardware hot swapping technologies. In modern computer systems, there are many hardware and limited interfaces. Not all devices are always connected to the computer. For example, USB Plug-in is inserted only when the USB drive is not connected to the computer. Therefore, some peripherals may not be connected when the system is powered on. Instead, connect to these devices as needed after startup. With the support of the 2.6 kernel, once new peripherals are connected to the system, the kernel can automatically discover them in real time, initialize these devices, and then use them. This provides great flexibility for users of portable devices.

However, these features pose some challenges to sysvinit. During system initialization, the device 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. If the printer is not connected to the system, starting these services is a waste. Sysvinit cannot deal with such requirements. It must start all the services that may be used at one time. Even if the printer is not connected to the system, the CUPS service must be started.

There is also a problem of attaching shared network disks. In/etc/fstab, you can specify that the system automatically mounts a network disk, such as NFS or iSCSI devices. In the first part of this article, we can see that the sysvinit analysis/etc/fstab mount file system step is before the network starts. However, if the network is not started, neither NFS nor iSCSI can be accessed, nor can it be mounted. Sysvinit adopts the netdev method to solve this problem, that is, when/etc/fstab finds a mount point of the netdev attribute, it does not try to mount it. After the network is initialized and enabled, there is also a dedicated netfs service to mount all these network disks. This is a last resort remedy, causing inconvenience to the Administrator. Some novice administrators have never even heard of the netdev option, so it is often a trap of system management.

In view of the above situations, after evaluating several optional init systems at that time, Ubuntu developers decided to redesign and develop a brand new init system, namely UpStart. UpStart is based on the event mechanism. For example, after the USB interface is inserted to the U disk, udev receives a kernel notification and finds the device. This is a new event. UpStart triggers a waiting task after the event is detected, such as processing the mount point in/etc/fstab. Using this event-driven model, upstart perfectly solves the new problems caused by plug-and-play devices.

In addition, the adoption of the event-driven mechanism has brought about some other beneficial changes, such as speeding up the system startup time. Sysvinit is blocked during runtime. When a script is running, the subsequent script must wait. This means that all initialization steps are executed in serial mode. In fact, many services are irrelevant to each other and can be started in parallel to reduce the startup time of the system. In the era when Linux is widely used in servers, the system startup time may not be so important. However, for desktop systems and portable devices, the duration of startup has a great impact on user experience. In addition, new Server technologies such as cloud computing often require a single device to start up more quickly.

UpStart meets these requirements. Currently, not only does Ubuntu use UpStart, but even RHEL of enterprise-level servers use UpStart to replace sysvinit as the init system by default.

Upstart features

UpStart solves the shortcomings of sysvinit mentioned earlier. With the event-driven model, UpStart can:

• Faster system startup
• Dynamic start of service when new hardware is detected
• The service is stopped dynamically when the hardware is removed.

These features allow UpStart to be well applied to desktop or portable systems to handle dynamic hardware plugging features in these systems.

Upstart concepts and terminologies

The basic concepts and Design of Upstart are clear and clear. The main concepts of UpStart are job and event. A Job is a work unit used to complete a Job, such as starting a background service or running a configuration command. Each Job waits for one or more events. Once an event occurs, upstart triggers the job to complete the corresponding work.

Job

A Job is a unit of work, a task or a service. It can be understood as a service script in sysvinit. There are three types of jobs:

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

A task job is a task that will be completed within a certain period of time, such as deleting a file;

A service job represents a background service process, such as apache httpd. The process will not exit here. Once it starts running, it will become a background genie process, managed by the init process. If such a process exits, it will be restarted by the init process, they can only stop sending signals by the init process. They are generally triggered by the dependent stop event. However, upstart also provides a command line tool that allows administrators to manually stop a service;

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

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

Job Lifecycle

Upstart maintains a lifecycle for each job. Generally, a job has the following statuses: Start, Run, and end. To describe changes in work more precisely, Upstart also introduces some other States. For example, before the start (pre-start), starting, and started, the current state of the job can be described more accurately.

Work starts from an initial state and changes gradually. It may have to go through several other States and finally enter another State to form a state machine. In this process, when the working status changes, the init process will issue an event ).

Table 1. Possible Job statuses in Upstart

Status name	Description
Waiting	Initial status
Starting	Job is about to begin
Pre-start	Execute the pre-start segment, that is, the work that should be completed before the task starts.
Spawned	Prepare to execute the script or exec segment
Post-start	Execute the post-start action
Running	Interim state set after post-start section processed denoting job is running (But it may have no associated PID !)
Pre-stop	Execute pre-stop segments
Stopping	Interim state set after pre-stop section processed
Killed	Task is about to be stopped
Post-stop	Execute the post-stop segment

Figure 1 shows the state machine of a Job.

Figure 1. Job's life cycle

There are four statuses that will cause the init process to send corresponding events, indicating the corresponding changes in the work:

• Starting
• Started
• Stopping
• Stopped

Other status changes do not trigger events. Then let's take a look at the detailed meaning of the event.

For more details, please continue to read the highlights on the next page:

1 2 3 Next Page