mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
[translated] 20150316 Systemd Boot Process a Close Look in Linux.md
This commit is contained in:
Frank Zhang
parent
de57e8d830
commit
528f2bb8b9
@ -1,151 +0,0 @@
|
||||
zpl1025
|
||||
Systemd Boot Process a Close Look in Linux
|
||||
================================================================================
|
||||
The way Linux system boots up is quite complex and there have always been need to optimize the way it works. The traditional boot up process of Linux system is mainly handled by the well know init process (also known as SysV init boot system), while there have been identified inefficiencies in the init based boot system, systemd on the other hand is another boot up manager for Linux based systems which claims to overcome the shortcomings of [traditional Linux SysV init][2] based system. We will be focusing our discussion on the features and controversies of systemd , but in order to understand it, let’s see how Linux boot process is handled by traditional SysV init based system. Kindly note that Systemd is still in testing phase and future releases of Linux operating systems are preparing to replace their current boot process with Systemd Boot manager.
|
||||
|
||||
### Understanding Linux Boot Process ###
|
||||
|
||||
Init is the very first process that starts when we power on our Linux system. Init process is assigned the PID of 1. It is parent process for all other processes on the system. When a Linux computer is started, the processor searches for the BIOS on the system memory, BIOS then tests system resources and find the first boot device, usually set as hard disk, it looks for Master Boot Record (MBR) on the hard disk, loads its contents to memory and passes control to it, the further boot process is controlled by MBR.
|
||||
|
||||
Master Boot Record initiates the Boot loader (Linux has two well know boot loaders, GRUB and LILO, 80% of Linux systems are using GRUB loaders), this is the time when GRUB or LILO loads the kernel module. Kernel module immediately looks for the “init” in /sbin partition and executes it. That’s from where init becomes the parent process of Linux system. The very first file read by init is /etc/inittab , from here init decides the run level of our Linux operating system. It finds partition table information from /etc/fstab file and mounts partitions accordingly. Init then launches all the services/scripts specified in the /etc/init.d directory of the default run level. This is the step where all services are initialized by init one by one. In this process, one service at a time is started by init , all services/daemons run in the background and init keeps managing them.
|
||||
|
||||
The shutdown process works in pretty much the reverse function, first of all init stops all services and then filesystem is un-mounted at the last stage.
|
||||
|
||||
The above mentioned process has some shortcomings. The need to replace traditional init with something better have been felt from long time now. Some replacements have been developed and implemented as well. The well know replacements for this init based system as Upstart , Epoch , Mudar and Systemd. Systemd is the one which got most attention and is considered to be better of all available alternatives.
|
||||
|
||||
### Understanding Systemd ###
|
||||
|
||||
Reducing the boot time and computational overhead is the main objective of developing the Systemd. Systemd (System Manager Daemon) , originally developed under GNU General Public License, is now under GNU Lesser General Public License, it is most frequently discussed boot and services manager these days. If your Linux system is configured to use Systemd boot manager, then instead of traditional SysV init, startup process will be handled by systemd. One of the core feature of Systemd is that it supports post boot scripts of SysV Init as well .
|
||||
|
||||
Systemd introduces the parallelization boot concept, it creates a sockets for each daemon that needs to be started, these sockets are abstracted from the processes that use them so they allow daemons to interact with each other. Systemd creates news processes and assigns every process a control group. The processes in different control groups use kernel to communicate with each others. The way [systemd handles the start up process][2] is quite neat, and much optimized as compared to the traditional init based system. Let’s review some of the core features of Systemd.
|
||||
|
||||
- The boot process is much simpler as compared to the init
|
||||
- Systemd provides concurrent and parallel process of system boot so it ensures better boot speed
|
||||
- Processes are tracked using control groups, not by PIDs
|
||||
- Improved ways to handle boot and services dependencies.
|
||||
- Capability of system snapshots and restore
|
||||
- Monitoring of started services ; also capabale of restarting any crashed services
|
||||
- Includes systemd-login module to control user logins.
|
||||
- Ability to add and remove components
|
||||
- Low memory foot prints and ability for job scheduling
|
||||
- Journald module for event logging and syslogd module for system log.
|
||||
|
||||
Systemd handles system shutdown process in well organized way as well. It has three script located inside /usr/lib/systemd/ directory, named systemd-halt.service , systemd-poweroff.service , systemd-reboot.service . These scripts are executed when user choose to shutdown, reboot or halt Linux system. In the event of shutdown, systemd first un-mount all file systems and disabled all swap devices, detaches the storage devices and kills remaining processes.
|
||||
|
||||
|
||||
|
||||
### Structural Overview of Systemd ###
|
||||
|
||||
Let’s review Linux system boot process with some structural details when it is using systemd as boot and services manager. For the sake of simplicity, we are listing the process in steps below:
|
||||
|
||||
**1.** The very first steps when you power on your system is the BIOS initialization. BIOS reads the boot device settings, locates and hands over control to MBR (assuming hard disk is set as first boot device).
|
||||
|
||||
**2.** MBR reads information from Grub or LILO boot loader and initializes the kernel. Grub or LILO will specify how to handle further system boot up. If you have specified systemd as boot manager in grub configuration file, then the further boot process will be handled by systemd. Systemd handles boot and services management process using “targets”. The ”target" files in systemd are used for grouping different boot units and start up synchronization processes.
|
||||
|
||||
**3.** The very first target executed by systemd is **default.target**. But default.target is actually a symlink to **graphical.target**. Symlink in linux works just like shortcuts in Windows. Graphical.target file is located at /usr/lib/systemd/system/graphical.target path. We have shown the contents of graphical.target file in the following screenshot.
|
||||
|
||||
|
||||
|
||||
**4.** At this stage, **multi-user.target** has been invoked and this target keeps its further sub-units inside “/etc/systemd/system/multi-user.target.wants” directory. This target sets the environment for multi user support. None root users are enabled at this stage of boot up process. Firewall related services are started on this stage of boot as well.
|
||||
|
||||
|
||||
|
||||
"multi-user.target" passes control to another layer “**basic.target**”.
|
||||
|
||||
|
||||
|
||||
**5.** "basic.target" unit is the one that starts usual services specially graphical manager service. It uses /etc/systemd/system/basic.target.wants directory to decide which services need to be started, basic.target passes on control to **sysinit.target**.
|
||||
|
||||
|
||||
|
||||
**6.** "sysinit.target" starts important system services like file System mounting, swap spaces and devices, kernel additional options etc. sysinit.target passes on startup process to **local-fs.target**. The contents of this target unit are shown in the following screenshot.
|
||||
|
||||
|
||||
|
||||
**7.** local-fs.target , no user related services are started by this target unit, it handles core low level services only. This target is the one performing actions on the basis of /etc/fstab and /etc/inittab files.
|
||||
|
||||
### Analyzing System Boot Performancev ###
|
||||
|
||||
Systemd offers tool to identify and troubleshoot boot related issues or performance concerns. **Systemd-analyze** is a built-in command which lets you examine boot process. You can find out the units which are facing errors during boot up and can further trace and correct boot component issues. Some useful systemd-analyze commands are listed below.
|
||||
|
||||
**systemd-analyze time** shows the time spent in kernel, and normal user space.
|
||||
|
||||
$ systemd-analyze time
|
||||
|
||||
Startup finished in 1440ms (kernel) + 3444ms (userspace)
|
||||
|
||||
**systemd-analyze blame** prints a list of all running units, sorted by the time taken by then to initialize, in this way you can have idea of which services are taking long time to start during boot up.
|
||||
|
||||
$ systemd-analyze blame
|
||||
|
||||
2001ms mysqld.service
|
||||
234ms httpd.service
|
||||
191ms vmms.service
|
||||
|
||||
**systemd-analyze verify** shows if there are any syntax errors in the system units. **Systemd-analyze plot** can be used to write down whole startup process to a SVG formate file. Whole boot process is very lengthy to read, so using this command we can dump the output of whole boot processing into a file and then can read and analyze it further. The following command will take care of this.
|
||||
|
||||
systemd-analyze plot > boot.svg
|
||||
|
||||
### Systemd Controversies ###
|
||||
|
||||
Systemd has not been lucky to receive love from everyone, some professionals and administrators have different opinions on its working and developments. Per critics of Systemd, it’s “not Unix-like” because it tried to replace some system services. Some professionals don’t like the idea of using binary configuration files as well. It is said that editing systemd configuration is not an easy tasks and there are no graphical tools available for this purpose.
|
||||
|
||||
### Test Systemd on Ubuntu 14.04 and 12.04 ###
|
||||
|
||||
Originally, Ubuntu decided to replace their current boot process with Systemd in Ubuntu 16.04 LTS. Ubuntu 16.04 is supposed to be released in April 2016, but considering the popularity and demand for Systemd, the upcoming **Ubuntu 15.04** will have it as its default boot manager. Good news is that the user of Ubuntu 14.04 Trusty Tahr And Ubuntu 12.04 Precise Pangolin can still test Systemd on their machines. The test process is not very complex, all you need to do is to include the related PPA to the system, update repository and perform system upgrade.
|
||||
|
||||
**Disclaimer** : Please note that its still in testing and development stages for Ubuntu. Testing packages might have any unknown issues and in worst case scenario, they might break your system configurations. Make sure you backup your important data before trying this upgrade.
|
||||
|
||||
Run following command on the terminal to add ppa to the your ubuntu system:
|
||||
|
||||
sudo add-apt-repository ppa:pitti/systemd
|
||||
|
||||
You will be seeing warning message here because we are trying to use temporary/testing PPA which is not recommended for production machines.
|
||||
|
||||
|
||||
|
||||
Now update the APT Package Manager repositories by running the following command.
|
||||
|
||||
sudo apt-get update
|
||||
|
||||
|
||||
|
||||
Perform system upgrade by running the following command.
|
||||
|
||||
sudo apt-get dist-upgrade
|
||||
|
||||
|
||||
|
||||
That’s all, you should be able to see configuration files of systemd on your ubuntu system now, just browse to the /lib/systemd/ directory and see the files there.
|
||||
|
||||
Alright, it’s time we edit grub configuration file and specify systemd as default Boot Manager. Edit grub file using Gedit text editor.
|
||||
|
||||
sudo gedit /etc/default/grub
|
||||
|
||||
|
||||
|
||||
Here edit GRUB_CMDLINE_LINUX_DEFAULT parameter in this file and specify the value of this parameter as: "**init=/lib/systemd/systemd**"
|
||||
|
||||
|
||||
|
||||
That’s all, your ubuntu system is no longer using its traditional boot manager, its using Systemd Manager now. Reboot your system and see the systemd boot up process.
|
||||
|
||||
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
Systemd is no doubt a step forward towards improving Linux Boot process; it’s an awesome suite of libraries and daemons that together improve the system boot and shutdown process. Many linux distributions are preparing to support it as their official boot manager. In future releases of Linux distros, we can hope to see systemd startup. But on the other hand, in order to succeed and to be adopted on the wide scale, systemd should address the concerns of critics as well.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/linux-how-to/systemd-boot-process/
|
||||
|
||||
作者：[Aun Raza][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://linoxide.com/author/arunrz/
|
||||
[1]:http://linoxide.com/booting/boot-process-of-linux-in-detail/
|
||||
[2]:http://0pointer.de/blog/projects/self-documented-boot.html
|
||||
@ -0,0 +1,150 @@
|
||||
走进Linux之systemd启动过程
|
||||
================================================================================
|
||||
Linux系统的启动方式有点复杂，而且总是有需要优化的地方。传统的Linux系统启动过程主要由著名的init进程（也被称为SysV init启动系统）处理，而基于init的启动系统也被确认会有效率不足的问题，systemd是Linux系统机器的另一种启动方式，宣称弥补了以[传统Linux SysV init][2]为基础的系统的缺点。在这里我们将着重讨论systemd的特性和争议，但是为了更好地理解它，也会看一下通过传统的以SysV init为基础的系统的Linux启动过程是什么样的。友情提醒一下systemd仍然处在测试阶段，而未来发布的Linux操作系统也正准备用systemd启动管理程序替代当前的启动过程。
|
||||
|
||||
### 理解Linux启动过程 ###
|
||||
|
||||
在我们打开Linux电脑的电源后第一个启动的进程就是init。分配给init进程的PID是1。它是系统其他所有进程的父进程。当一台Linux电脑启动后，处理器会先在系统存储中查找BIOS，之后BIOS会测试系统资源然后找到第一个引导设备，通常设置为硬盘，然后会查找硬盘的主引导记录（MBR），然后加载到内存中并把控制权交给它，以后的启动过程就由MBR控制。
|
||||
|
||||
主引导记录会初始化引导程序（Linux上有两个著名的引导程序，GRUB和LILO，80%的Linux系统在用GRUB引导程序），这个时候GRUB或LILO会加载内核模块。内核会马上查找/sbin下的init进程并执行它。从这里开始init成为了Linux系统的父进程。init读取的第一个文件是/etc/inittab，通过它init会确定我们Linux操作系统的运行级别。它会从文件/etc/fstab里查找分区表信息然后做相应的挂载。然后init会启动/etc/init.d里指定的默认启动级别的所有服务/脚本。所有服务在这里通过init一个一个被初始化。在这个过程里，init每次只启动一个服务，所有服务/守护进程都在后台执行并由init来管理。
|
||||
|
||||
关机过程差不多是相反的过程，首先init停止所有服务，最后阶段会卸载文件系统。
|
||||
|
||||
以上提到的启动过程有一些不足的地方。而用一种更好的方式来替代传统init的需求已经存在很长时间了。也产生了许多替代方案。其中比较著名的有Upstart，Epoch，Muda和Systemd。而Systemd获得最多关注并被认为是目前最佳的方案。
|
||||
|
||||
### 理解Systemd ###
|
||||
|
||||
开发Systemd的主要目的就是减少系统引导时间和计算开销。Systemd（系统管理守护进程），最开始以GNU GPL协议授权开发，现在已转为使用GNU LGPL协议，它是如今讨论最热烈的引导和服务管理程序。如果你的Linux系统配置为使用Systemd引导程序，那么代替传统的SysV init，启动过程将交给systemd处理。Systemd的一个核心功能是它同时支持SysV init的后开机启动脚本。
|
||||
|
||||
Systemd引入了并行启动的概念，它会为每个需要启动的守护进程建立一个管道套接字，这些套接字对于使用它们的进程来说是抽象的，这样它们可以允许不同守护进程之间进行交互。Systemd会创建新进程并为每个进程分配一个控制组。处于不同控制组的进程之间可以通过内核来互相通信。[systemd处理开机启动进程][2]的方式非常漂亮，和传统基于init的系统比起来优化了太多。让我们看下Systemd的一些核心功能。
|
||||
|
||||
- 和init比起来引导过程简化了很多
|
||||
- Systemd支持并发引导过程从而可以更快启动
|
||||
- 通过控制组来追踪进程，而不是PID
|
||||
- 优化了处理引导过程和服务之间依赖的方式
|
||||
- 支持系统快照和恢复
|
||||
- 监控已启动的服务；也支持重启已崩溃服务
|
||||
- 包含了systemd-login模块用于控制用户登录
|
||||
- 支持加载和卸载组件
|
||||
- 低内存使用痕迹以及任务调度能力
|
||||
- 记录事件的Journald模块和记录系统日志的syslogd模块
|
||||
|
||||
Systemd同时也清晰地处理了系统关机过程。它在/usr/lib/systemd/目录下有三个脚本，分别叫systemd-halt.service，systemd-poweroff.service，systemd-reboot.service。这几个脚本会在用户选择关机，重启或待机时执行。在接收到关机事件时，systemd首先卸载所有文件系统并停止所有内存交换设备，断开存储设备，之后停止所有剩下的进程。
|
||||
|
||||
|
||||
|
||||
### Systemd结构概览 ###
|
||||
|
||||
让我们看一下Linux系统在使用systemd作为引导程序时的开机启动过程的结构性细节。为了简单，我们将在下面按步骤列出来这个过程：
|
||||
|
||||
**1.** 当你打开电源后电脑所做的第一件事情就是BIOS初始化。BIOS会读取引导设备设定，定位并传递系统控制权给MBR（假设硬盘是第一引导设备）。
|
||||
|
||||
**2.** MBR从Grub或LILO引导程序读取相关信息并初始化内核。接下来将由Grub或LILO继续引导系统。如果你在grub配置文件里指定了systemd作为引导管理程序，之后的引导过程将由systemd完成。Systemd使用“target”来处理引导和服务管理过程。这些systemd里的“target”文件被用于分组不同的引导单元以及启动同步进程。
|
||||
|
||||
**3.** systemd执行的第一个目标是**default.target**。但实际上default.target是指向**graphical.target**的软链接。Linux里的软链接用起来和Windows下的快捷方式一样。文件Graphical.target的实际位置是/usr/lib/systemd/system/graphical.target。在下面的截图里显示了graphical.target文件的内容。
|
||||
|
||||
|
||||
|
||||
**4.** 在这个阶段，会启动**multi-user.target**而这个target将自己的子单元放在目录“/etc/systemd/system/multi-user.target.wants”里。这个target为多用户支持设定系统环境。非root用户会在这个阶段的引导过程中启用。防火墙相关的服务也会在这个阶段启动。
|
||||
|
||||
|
||||
|
||||
"multi-user.target"会将控制权交给另一层“**basic.target**”。
|
||||
|
||||
|
||||
|
||||
**5.** "basic.target"单元用于启动普通服务特别是图形管理服务。它通过/etc/systemd/system/basic.target.wants目录来决定哪些服务会被启动，basic.target之后将控制权交给**sysinit.target**.
|
||||
|
||||
|
||||
|
||||
**6.** "sysinit.target"会启动重要的系统服务例如系统挂载，内存交换空间和设备，内核补充选项等等。sysinit.target在启动过程中会传递给**local-fs.target**。这个target单元的内容如下面截图里所展示。
|
||||
|
||||
|
||||
|
||||
**7.** local-fs.target，这个target单元不会启动用户相关的服务，它只处理底层核心服务。这个target会根据/etc/fstab和/etc/inittab来执行相关操作。
|
||||
|
||||
### 系统引导性能分析 ###
|
||||
|
||||
Systemd提供了工具用于识别和定位引导相关的问题或性能影响。**Systemd-analyze**是一个内建的命令，可以用来检测引导过程。你可以找出在启动过程中出错的单元，然后跟踪并改正引导组件的问题。在下面列出一些常用的systemd-analyze命令。
|
||||
|
||||
**systemd-analyze time** 用于显示内核和普通用户空间启动时所花的时间。
|
||||
|
||||
$ systemd-analyze time
|
||||
|
||||
Startup finished in 1440ms (kernel) + 3444ms (userspace)
|
||||
|
||||
**systemd-analyze blame** 会列出所有正在运行的单元，按从初始化开始到当前所花的时间排序，通过这种方式你就知道哪些服务在引导过程中要花较长时间来启动。
|
||||
|
||||
$ systemd-analyze blame
|
||||
|
||||
2001ms mysqld.service
|
||||
234ms httpd.service
|
||||
191ms vmms.service
|
||||
|
||||
**systemd-analyze verify** 显示在所有系统单元中是否有语法错误。**systemd-analyze plot** 可以用来把整个引导过程写入一个SVG格式文件里。整个引导过程非常长不方便阅读，所以通过这个命令我们可以把输出写入一个文件，之后再查看和分析。下面这个命令就是做这个。
|
||||
|
||||
systemd-analyze plot > boot.svg
|
||||
|
||||
### Systemd的争议 ###
|
||||
|
||||
Systemd并没有幸运地获得所有人的青睐，一些专家和管理员对于它的工作方式和开发有不同意见。根据对于Systemd的批评，它不是“类Unix”方式因为它试着替换一些系统服务。一些专家也不喜欢使用二进制配置文件的想法。据说编辑systemd配置非常困难而且没有一个可用的图形工具。
|
||||
|
||||
### 在Ubuntu 14.04和12.04上测试Systemd ###
|
||||
|
||||
本来，Ubuntu决定从Ubuntu 16.04 LTS开始使用Systemd来替换当前的引导过程。Ubuntu 16.04预计在2016年4月发布，但是考虑到Systemd的流行和需求，即将发布的**Ubuntu 15.04**将采用它作为默认引导程序。好消息是Ubuntu 14.04 Trusty Tahr和Ubuntu 12.04 Precise Pangolin的用户可以在他们的机器上测试Systemd。测试过程并不复杂，你所要做的只是把相关的PPA包含到系统中，更新仓库并升级系统。
|
||||
|
||||
**声明**：请注意它仍然处于Ubuntu的测试和开发阶段。升级测试包可能会带来一些未知错误，最坏的情况下有可能损坏你的系统配置。请确保在尝试升级前已经备份好重要数据。
|
||||
|
||||
在终端里运行下面的命令来添加PPA到你的Ubuntu系统里：
|
||||
|
||||
sudo add-apt-repository ppa:pitti/systemd
|
||||
|
||||
你将会看到警告信息因为我们尝试使用临时/测试PPA，而它们是不建议用于实际工作机器上的。
|
||||
|
||||
|
||||
|
||||
然后运行下面的命令更新APT包管理仓库。
|
||||
|
||||
sudo apt-get update
|
||||
|
||||
|
||||
|
||||
运行下面的命令升级系统。
|
||||
|
||||
sudo apt-get dist-upgrade
|
||||
|
||||
|
||||
|
||||
就这些，你应该已经可以在你的Ubuntu系统里看到Systemd配置文件了，打开/lib/systemd/目录可以看到这些文件。
|
||||
|
||||
好吧，现在让我们编辑一下grub配置文件指定systemd作为默认引导程序。可以使用Gedit文字编辑器编辑grub配置文件。
|
||||
|
||||
sudo gedit /etc/default/grub
|
||||
|
||||
|
||||
|
||||
在文件里修改GRUB_CMDLINE_LINUX_DEFAULT项，设定它的参数为：“**init=/lib/systemd/systemd**”
|
||||
|
||||
|
||||
|
||||
就这样，你的Ubuntu系统已经不在使用传统的引导程序了，改为使用Systemd管理器。重启你的机器然后查看systemd引导过程吧。
|
||||
|
||||
|
||||
|
||||
### 结论 ###
|
||||
|
||||
Systemd毫无疑问为改进Linux引导过程前进了一大步；它包含了一套漂亮的库和守护进程配合工作来优化系统引导和关闭过程。许多Linux发行版正准备将它作为自己的正式引导程序。在以后的Linux发行版中，我们将有望看到systemd开机。但是另一方面，为了获得成功并广泛应用，systemd仍需要认真处理批评意见。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://linoxide.com/linux-how-to/systemd-boot-process/
|
||||
|
||||
作者：[Aun Raza][a]
|
||||
译者：[zpl1025](https://github.com/zpl1025)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://linoxide.com/author/arunrz/
|
||||
[1]:http://linoxide.com/booting/boot-process-of-linux-in-detail/
|
||||
[2]:http://0pointer.de/blog/projects/self-documented-boot.html
|
||||
Loading…
Reference in New Issue
Block a user