Linux system startup process

First, start the general flowchart

Kernel and INITRD: Probe hardware-load driver (INITRD, Micro Linux), mount root file system->rootfs (/sbin/init). INITRD is not a must.

Two or three the main init

Narrated three major Init systems: Sysvinit,upstart and SYSTEMD

1, Sysvinit

Sysvinit sequential operation (serial), the concept is simple and clear, slow start. The startup process is as follows:
Init--->inittab (runlevel)--->rc.sysinit (System initialization)--->RC--->rcx.d (Start-stop service)--->rc.local--->tty and login

Disadvantage: Frequent use of hardware hot-plug technology, sysvinit need to start all possible use of hardware corresponding services, network share Disk (NFS, ISCSI), need to netfs services to mount all these network disks; boot slow.

2, Upstart

The upstart uses an event-driven model. Start the system faster (in parallel), dynamically start the service when new hardware is discovered, and dynamically stop the service when the hardware is removed.

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.

Boot upstart first generates the Startup event.

3, Systemd

The biggest features of SYSTEMD are two:
(1), providing a more aggressive parallel start-up capability than upstart, using Socket/d-bus activation and other technology to start the service. The result: Faster start-up speed.
(2), with CGroup statistical tracking sub-process, clean and reliable.

3.1. Parallel socket
For traditional Unix daemon, the real dependency on each other is the socket provided by the service.
If the client program must be set up as soon as possible and the client program waits instead of starting the client program after the service program is fully started, we can speed up the boot process and further parallelize the process start up.
3.2. Parallel bus service
Modern daemon on Linux interact with Dbus rather than sockets.
Dbus has provided all the necessary hooks: using Dbus will load the service on the first visit and give the smallest, one-per-request synchronization mechanism that is initiated simultaneously by the consumer and the producer.
For example, Avahi and cups (cups need avahi for MDNS/DNS-SD on the printer) start at the same time, simply start both at the same time, if cups is faster than the Avahi boot, then Dbus will cache the request into the queue until the Avahi service is processed.

This is summarized as follows: socket-based and Dbus-based services can start all processes in parallel at once without any additional synchronization. The activation-based policy also allows us to delay loading the service. If the service is seldom used, we can start it when it is first accessed, not during the boot process.

3.3. Parallel File system Tasks
During system startup, file system related activity is the most time consuming, such as Mount file system, fsck, disk quota check, etc.
SYSTEMD integrates the implementation of AutoFS, and for mount points in the system, such as/home, when the system starts, SYSTEMD creates a temporary automatic mount point for it. At this time/home real Mount device has not been started well, the real mount operation has not been executed, file system detection has not been completed. However, the processes that depend on the directory can already be started concurrently, and their open () operations are captured by AutoFS built into SYSTEMD, suspending the open () call (sleep state can be interrupted). Then wait for the real mount operation to complete, and after file system detection is complete, SYSTEMD replaces the automatic mount point with the true mount point and makes the open () call back. As a result, services that rely on the file system and the file system itself are implemented concurrently to start.

3.3.1, three init start time

3.3.2, SYSTEMD set the run level:
The first goal Systemd performed is Default.target
Gets the current runlevel: Systemctl get-default
Settings: Systemctl set-default multi-user.target
/lib/systemd/system/default.target-Graphical.target

3.3.3, Systemd, and Sysvinit run level correspondence table

Linux system startup process