1.7 Systemd initialization process

The Linux operating system starts by starting with BIOS, then entering Boot Loader, loading the system kernel, then initializing the kernel, and finally starting the initialization process. A s the first process of linux system, the initialization process needs to complete the relevant initialization work in Linux system to provide the user with the appropriate working environment. T he Red Hat RHEL 7 system has replaced the familiar initialization process service System V init and officially adopted the new Systemd Initialization Process service. I f you studied the RHEL 5 or RHEL 6 systems before, you may not be used to it. S ystemd initialization process service uses a synth start-up mechanism, the boot speed has been greatly improved. Although systemd initialization process services have many new features and benefits, they are currently the following four slots.

Lennot Poettering, a developer of the system's initialization process service, worked for Red Hat, much to the chastity of fans of other systems.

Slot 2: The systemd initialization process service can only run under Linux systems, "abandoning" UNIX system users.

Slot 3: Systemd takes over services such as syslogd, udev, cgroup, and is no longer willing to do only initial process services.

Slot 4: After using systemd initialization process service, the RHEL 7 system changes too much, and the relevant reference documentation is not much, which makes it difficult for the user.

In any case, it is an established fact that the RHEL 7 system selects systemd initialization process services, so there is no concept of "run level", linux systems start up with a lot of initialization work, such as mounting file systems and switching partitions, starting various process services, etc., which can be regarded as a unit, systemd with a target instead of the concept of running level in System Vit, The difference between the two is shown in Table 1-3.

The difference between Table 1-3 systemd and System V init and its role

• System V init run-level systemd target name role
• 0 runlevel0.target, poweroff.target shut down
• 1 runlevel1.target, rescue.target single-user mode
• 2 runlevel2.target, multi-user.target equivalent to level 3
• 3 runlevel3.target, multi-user.target multi-user multi-user text interface
• 4 runlevel4.target, multi-user.target is equivalent to level 3
• 5 runlevel5.target, graphical.target multi-user graphical interface
• 6 runlevel6.target, reboot.target restart
• emergency emergency.target emergencyshell

If you want to modify the system's default run target to "multi-user, no graphics" mode, you can connect the multi-user mode target file directly to /etc/system/system/directory with the ln command:

[root@linuxprobe ~]# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

If a reader has studied the RHEL 6 system before, or is used to using commands such as service and chkconfig to manage the service, it is more frustrating now, because the system in THERHEL 7 uses the system to manage the service using the system. When you compare the System V init command in the RHEL 6 system shown in Tables 1-4 and 1-5 with the Systemctl command in the RHEL 7 system, you can get a general idea of how often they are used in subsequent sections.

Table 1-4 Systemctl manages common commands such as start, restart, stop, overload, view status, and so on

• System V init Command (RHEL 6 System) Systemctl Command (RHEL 7 System) functions
• Service foo start systemctl start foo.service start service
• Service foo restart systemctl restart foo.service restart service
• Service foo stop systemctl stop foo.service stop service
• service foo reload systemctl reload foo.service reload profile (no termination of service)
• Service foo status systemctl status foo.service to view the status of the service

Table 1-5 systemctl sets common commands such as service boot, non-start, view service start status at all levels, and so on

• System V init Command (RHEL 6 System) Systemctl Command (RHEL 7 System) functions
• chkconfig foo on systemctl enable foo.service boot starts automatically
• chkconfig foo off systemctl disable foo.service boot does not start automatically
• chkconfig foo systemctl is-enabled foo.service to see if a particular service is booted
• chkconfig --list systemctl list-unit-files--type-service to see how services are started and disabled at all levels