Linux Startup: replace traditional init with upstart

For a long time, most Linux distributions have been using the init system introduced by UNIX System V. Init is generated by the kernel itself. The task is to start the remaining part of the system, generate and monitor all other processes, and check whether it is stopped or frozen. Although System V init has been running well in the past, it is a little late. This is why Ubuntu 6.10 (edgy EFT) uses upstart to replace the aging init system.

The goal of upstart design is to provide a mechanism to replace System V Init (sysvinit), which is different from other developed init replacements. Because the current desktop computers and servers are very different from those of the past 10 years, some problems have occurred while trying to continue operating the system in Ubuntu.

In the past, the startup operations were relatively simple, such as checking and mounting the file system. Only limited hardware is supported. The device is connected when the device is powered on, and the device is disconnected when the device is powered off. The kernel knows the disk type and number, so the Startup Process of the user space does not need to check and mount them.

Process new hardware

Current systems must process new hardware that can be connected to more complex topology buses with almost no limit. These new devices can be plug-and-play and do not require power supply before use, which means that the kernel will receive this information when the hardware changes. The problem that occurs during hardware connection Initialization is: no response method is available.

In the case of a wireless network file system, the problem is even greater. We must not only wait for the server to respond, but also configure the network interface. It involves uploading firmware to a card through a wireless access point, requesting an IP address from the network server, and logging on to the webpage to obtain Internet access.

Solutions to these problems already exist. For example, UBUNTU finds the hardware that is likely to exist after detecting the file system, and waits until the expected hardware detection is completed cyclically. These methods depend on the waiting time at startup, and the premise is that the hardware waiting is known. Generally, if you want to start faster, the better, the longer the startup wait method will not last. It may be feasible to know the hardware information in advance, but the hardware's continuous introduction of new features breaks this assumption.

We may be able to use the Background ServiceProgramSolution. For example, in the HP Linux image printing system, the image is randomly started and runs. Once the hardware is connected, the image can be used immediately. In this way, users who own the hardware will benefit, and users who do not have the hardware will have no loss. But more interesting is that the service program runs only when the hardware is connected.

The Linux kernel has become better and better in terms of hardware support. With the introduction of udev, the kernel driver core and user space can all know the hardware connection information. Despite this, we still rely on some shell scripts set for the Startup Program. The hardware availability in the startup process is still assumed.

Other methods to update the init system

Previously, the init system was replaced. For example, the LSB specification and initng both focus on automatically determining the script sequence and allow the script to start in parallel. Both of them reduce the burden on developers and speed up startup.

Other systems, such as Solaris SMF and Runit, are used to solve service management problems and allow system administrators to query and change the status and settings of running services. Finally, Apple's launchd does not solve any problems. It provides a background to replace traditional UNIX services such as init, Cron, and inetd.

The above system has not solved our problems. We need an init backend, which allows us to select and sort scripts by events from outside the init system (such as udev), rather than making decisions by the script itself. In fact, the init sequence we need is determined by these events and themselves.

In order to avoid overhead, we should first look at how much effort is needed to modify the existing method. Sun SMF and Apple launchd are directly excluded due to license issues. The solution should first be "free" and follow GPL, so that other release versions can be used.

Look at initng. Before udev was released, can the problem be solved by scripts? But we do not think it is better than the existing method. Features introduced using the LSB specification do not need to replace the init background program and can be implemented using existing init scripts.

The system we need is: The file systems listed in/etc/fstab check and load when the kernel detects Block devices. Similarly, when the kernel detects the network, it configures the NIC. If an IP address is obtained, it tries to load the remote system. If an event is generated after the script is complete, other scripts and background services can be started.

Event-based init daemon

The design uses the term event-based init daemon. There are two types of tasks to be managed: script and binary. Events trigger or stop them. Init daemon generates specific events at specific points, such as startup and shutdown, and any other tasks that can change the status. Other events can be generated by other parts of the system, such as udev.

Compare with the dependency-based init daemons such as initng. Each task corresponds to a list of dependencies, and the part on which it depends is started when the task is required. This requires an end-to-end set of targets to ensure that all the startup starts. Generally, different runlevels are used to solve the problem.

The dependency-based init daemon starts the network because Apache needs it, and the file system is mounted because the network needs to be like this for Apache and gmt1. If a failure occurs during the startup of the target group, the network will not be valid unless the network itself is one of the target sets.

Event-based init daemon startup originates from a separate event, such as "Startup ". Runlevels is not required. The system can be started as long as the hardware is effective. For the release version, the default installation is more flexible. As long as the network card is valid, it starts. In a dependency-based system, if the network adapter is not connected to Apache at the startup time, it will not start. For event-based systems, if the network card is inserted several minutes later, Apache will automatically start.

The procedure for mounting a file system is as follows:

1. The "Startup" event enables udev background startup.
2. Configure the udev background and send a "Block device added" event to all new block devices.
3. If the block device is added to the fstab list, the device is detected and mounted.
4. When all the file systems specified by FHS listed in fstab are mounted, the "FHS-filesystem" event is sent.

In addition, we can configure network interfaces and mount remote file systems:

1. The udev background sends a "Network Interface added" event to all new network interfaces.
2. If the "Network Interface added" event is in the/etc/Network/interfaces list, the interface is activated and configured.
3. An "Network Interface activation" event is sent when an IP address is obtained.
4. Set the default gateway to trigger the "Default Gateway activation" event to be sent.
5. These events enable the system to mount a remote file system and cause the "FHS-filesystem" event.

No matter how you configure these event chains, the corresponding part of the system starts to run. If the system does not depend on any network file system and does not need to adjust the dependency of the task, the event will automatically configure it.

Define events

The event itself is a simple string that uses environment variables to deliver more detailed information to the task for processing the event. Add parameters or sources to identify the added device or task that has stopped. Using the "initctl" tool, any part of the system can issue events, or communicate directly with init through Unix domain sockets.

The/etc/event. d directory defines jobs. The simplest is: binary file name, or shellCode. Slightly complicated: shell code to be executed before or after the task starts, as well as resource restrictions and environment settings. Job startup time: any event in the list occurs. When another event occurs, they can suspend themselves, stop or re-Execute normally.

This project aims to simplify system configuration. Currently, you must configure tasks by yourself, whether at startup, after the network device is activated, connected to an AC power source, or when the system is sleeping.

Because the event can be captured by any other process in the system, we want to modify the other background to replace the execution Script directory. They send the event to init and then all these tasks can be performed in/etc/event. D is configured. Future Potential Includes executing tasks based on user habits, replacing Cron, anacron, and ATD with inetd background with time-based events.

Using upstart can solve many problems, making Linux more friendly, avoiding competition and ugly work areas, and making the system administrator easier.

Upstart is applicable to any Linux release instead of sysvinit. Note that, like other alternative mechanisms, it also has its own configuration. It does not execute an existing init script Unless the configuration permits execution. The recommended porting plan is (which Ubuntu follows): Execute the existing system v rc Script and let it be responsible for the legacy init script.

The edgy EFT repository contains upstart. Try upstart immediately.