CentOS 7 system detailed boot process and shutdown process

Source: Internet
Author: User

Name Bootup-The system startup process describes several different components to be involved in the system startup process.    After pressing the power-on button, first bios/uefi to do the most basic hardware self-test and initialization, and then load the preset/manually selected disk/network boot loader (such as GRUB2), boot loader further from the disk/Network load operating system kernel (such as Linux). For Linux, the kernel will (optionally) extract a initrd (initial RAM disk) image (which can be generated with tools from the Dracut Class) and execute the INIT program specified by the "rdinit=" kernel boot parameter (for examplesystemd) to locate and mount the root file system.     After the root file system is mounted, the kernel launches the INIT program (for example, SYSTEMD) specified by the "init=" kernel boot parameter to take over control of the system.    The INIT program will be responsible for detecting all other hardware devices, mounting the necessary file systems, starting all necessary services, and so on. When the computer shuts down, the INIT program will stop all services, unmount all file systems, and (optionally) return to the INITRD environment to unload the root filesystem and finally turn off the power. General start-up process when the root filesystem specified by the "root=" kernel boot parameter is successfully mounted, the kernel launches the INIT program specified by the "init=" kernel boot parameter, starting at that point, entering the "General boot process": Detecting hardware devices and loading drivers, mounting the necessary file systems,    Start all the necessary services, and so on.    For the SYSTEMD system, the above "init program" is the SYSTEMD process, and the entire "normal START process" is also a few special target units (see) as a node, is divided into several stages steps.    Within each stage step, the task is highly parallel, so the order of the cells within it cannot be accurately predicted, but the order of the phases is always fixed.    When the system is started, the SYSTEMD will start with Default.target, and the "normal start process" can be accomplished with the interlocking dependencies between the units.    Typically, Default.target is just a soft connection to the Graphical.target (graphical interface) or Multi-user.target (text console).    In order to enforce the normalization of the process and improve the parallelism of the unit, some target units with specific meanings are defined beforehand.    The following diagram explains the dependencies between these target units with a specific meaning and their location in the startup process.    The arrows in the diagram indicate the dependencies and sequencing of the cells, and the entire chart is executed in a top-down chronological order.             Local-fs-pre.target |        V (each mounts and (each swap (each cryptographic block device fsck Services) devices) devices) (each of the underlying services                  (each underlying API virtual |             |     | SERVICES:UDEVD, file system Mounts:v v v tmpfiles, random mqu      Eue, Configfs, Local-fs.target swap.target cryptsetup.target seed, sysctl ...)             Debugfs ...)                  |                  |                    |                    |             | \__________________|_________________ |                                                   ___________________|____________________/                                                  \|/                                                   V Sysinit.target              |                  ____________________________________/|\________________________________________             /                  |                    |                                 |                  |                  |                    |                    |             |          V V |          V V (Individual timers) (Individual paths) |                  (each sockets) Rescue.service |                  |                    |                    |             |                    V V |             V V timers.target Paths.target |         Sockets.targetRescue.target|                  |                    |             | V \_________________ |                                    ___________________/             .                                                   \|/...................vbasic.target              |                                 ____________________________________/|                  Emergency.service/|                                         |             |                  |                  |                                         | V V v VEmergency.targetdisplay-(various system services required by the graphical interface (each system service) Manager.service) |                  |                  |                  V | |Multi-user.target|                  |             | \_________________ | _________________/\|/VGraphical.target    Target cells identified in bold underlines are often used as starting targets.    There are two ways to specify a startup target: (1) Use the systemd.unit= kernel command-line parameter (see SYSTEMD Manual), and (2) use a default.target soft connection. Because Timers.target is included asynchronously in Basic.target, the timer unit can rely on services that start after basic.target.    INITRD the START process is internal to INITRD, or you can use SYSTEMD as the INIT program (specified by the rdinit= kernel boot parameter), Initrd.target will be the default target.    INITRD the upper part of the internal start process is exactly the same as before the previous section Basic.target, followed by the startup process as shown.    If the root file system is successfully mounted to the/sysroot directory, then the Sysroot.mount unit is activated and the Initrd-root-fs.target target is further activated.    Initrd-parse-etc.service will parse the/sysroot/etc/fstab file to mount the/usr (if required) with the mount point with the x-initrd.mount tag.    These mount points are mounted under/sysroot, and the process reaches the initrd-fs.target target. Next Initrd-cleanup.service will start Initrd-switch-root.target with/usr/bin/systemctl--no-block isolate INITRD-SWI command Tch-root.target Target.    Because isolate means to stop all processes that are not needed in the new target cell immediately, this action is actually prepared for the next switch root directory (that is, to clean up the environment).                                    Finally, activate the Initrd-switch-root.service service to switch the root directory of the system to the/sysroot directory.                             (The previous process is exactly the same as in the previous section):                      V Basic.target                                 |                                         Emergency.service ______________________/|                           |                                         /                       |                  V |                       Sysroot.mount Emergency.target |                           |                       |             V |                       Initrd-root-fs.target |                           |                       |                   V v initrd-parse-etc.service (each custom |            INITRD Services) v |        (Sysroot-usr.mount and |    Fstab with X-initrd.mount |                       Tags for each mount point) |                           |                       |                V |                                                  Initrd-fs.target \______________________ |                                                   \|                                                   V Initrd.target |                                V Initrd-cleanup.service                                                   (use isolates to start Initrd-switch-root.target) |                           V ______________________/|        /V |                       Initrd-udevadm-cleanup-db.service    V |                  (each custom-defined |                           INITRD Services) |                                                  \______________________ |                                                   \|                                                   V Initrd-switch-root.target |                                                   V Initrd-switch-root.service                                                   |   V Switch to the operating system shutdown process on the host SYSTEMD system also follows a fixed process when shutting down, as shown in: (Mutual exclusion from all system services)                                      (with all file systems mounts, swaps, cryptsetup devices Mutex) |                              | V v shutdown.target umount.tArget |                              |                                                      \______________________   _____________/                                                     \ /                                                      V (each underlying services)                                                      |                V Final.target |                         _____________________________________/ \_________________________________               /                        |                                     |                         |                        |                      |               | V v v v Systemd-reboot.service systemd-poweroff.s Ervice Systemd-halt.service Systemd-kexec.service              |                        |                      |               |         V V v Vreboot.target poweroff.target halt.target kexec.targetTarget cells identified in bold underlines are often used as shutdown targets.

CentOS 7 system detailed boot process and shutdown process

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.