定制和监视 Linux 系统启动 -2

look_w

了解和使用 systemd                当 Upstart 似乎注定要在 Linux 系统中全面替代 SysVinit 的时候，另一种前途更耀眼、更闪耀和更高效的启动机制出现了：systemd （系统守护进程），最初由 Leonard Poettering 编写。systemd 系统启动机制通过了解各种服务需要和使用的基本资源，大大提高了并行化系统启动的性能。systemd 还使用了自从 2.6 内核以后的版本中都支持的控制组 (cgroups) 机制，让跟踪和管理相关进程的资源变得更容易。          
                大部分现代的 Linux 服务与相关客户端都使用了 UNIX 套接字来实现进程间通信，包括用于与一般硬件相关的、本地的应用间消息的 D-Bus 消息总线。当所需的套接字存在或 D-Bus 被激活时，就可以启动使用它们的任何服务，因此 systemd 首先创建与您想要在指定系统上启动的服务相关的所有套接字。使用这些资源的服务通常会受到阻塞，直到它们需要发送或接收消息为止，因此，要么并行地启动它们，要么根据传入的请求按需启动它们。      
        创建逻辑资源以启动可能并行使用这些资源的服务并不仅限于客户端与服务器。与随需文件系统访问机制（如 autofs）结合在一起之后，即使是系统启动过程中一般较慢的部分（比如文件系统一致性检查与挂载），也可以针对根文件系统（所有人都始终需要它）以外的文件系统使用这种模型。在结束文件系统挂载之后，就可以使用文件或文件系统更改事件来触发使用内核的 fanotify 与 fsnotify 机制的其他操作。          
systemd 启动机制指的是作为单元 进行管理的所有内容。为了满足不同类型的初始化和启动需求，systemd 支持不同类型的单元， 列出了其中最常用的一些单元。          
表 2. systemd 的常用单元类型单元类型说明automount            确定随需文件系统访问机制（如 autofs）使用的文件系统挂载点。每个 automount 单元都有一个相匹配的 mount 单元。          device                  代表 udev 规则针对的物理设备。          mount            确定一个标准的文件系统挂载点。          service            定义一个可被启动、停止、重新启动、重新加载等的守护进程。因为这些是由 SysVinit 启动机制完成的传统类型的工作，systemd 可以自动解析 SysVinit 启动脚本中的 LSB 注释（在  一节中讨论过这一点），并正确使用这些信息。          socket            代表一个标准类型的文件系统或网络套接字，比如 AF_INET 或 AF_UNIX，这样通向这些套接字的传入连接就可以触发启动相关服务          target            定义一个用于对概念相关的其他单元进行分组的逻辑单元。例如，systemd 使用 graphical.target 单元来收集在图形设备变为可用时，应该在带有图形化控制台的系统上启动的所有应用程序。         
                与 systemd 支持的单元类型有关联的服务配置文件通常位于 /etc/systemd 的子目录中。 就是 systemd 服务配置文件的一个例子。          
清单 4. 一个样例 systemd 服务配置文件

1 2 3 4 5 6 7 8 9 10 11 12

[Unit] Description=System Logging Service [Service] EnvironmentFile=-/etc/sysconfig/rsyslog ExecStart=/sbin/rsyslogd -n $SYSLOGD_OPTIONS Sockets=syslog.socket StandardOutput=null [Install] WantedBy=multi-user.target Alias=syslog.service

        这个文件是 Fedora 17 rsyslog.service 系统中系统日志的单元定义，位于 /etc/systemd/system/multi-user.target.wants 目录中。可以看出，这个文件的多处均描述了与它相关联的单元，说明如何启动服务以及它使用哪些资源，并说明在何种情况下调用单元—在这个例子中，是当系统的启动目标为 multi-user.target 时。      
systemd 启动机制使用 systemctl 命令，在命令行中启动、停止与检查各类单元的状态。systemadm 命令功能相同，但具有图形化的界面，默认不安装。要添加此命令，必须安装 systemd-gtk 包。      
systemd 启动机制可以带来实质性的性能提升，但如果需要在启动次序中的一个具体的确定点上添加命令，则需要更高的技巧。尽管 systemd 很值得一试，看它在特定系统上是否能提高启动性能，但并非所有人都喜欢它，因为 systemd 与以前的 Linux 启动机制有很大的不同。请参见  中关于 systemd 的反面观点的链接。新方法固然有趣，但可能很快就变得很平常。      
        监控系统启动和脚本执行             如果要将系统变为可用的时间缩至最短，那么只是测量在按下电源后系统变为可用所花费的时间长短并不能提供很多有用的信息。您真正感兴趣的真实数据应该如下所示：      

•                   系统启动期间执行了哪些初始化命令或脚本？
•                   这些命令或脚本按照什么顺序执行？
•                   每个命令后脚本花费了多长时间？

                如果要在系统的启动过程中添加一个脚本，您应该一开始就关注它是否确实得到了执行，以及它在什么点上被执行。确定这些信息的一种简便途径是在脚本中调用 /usr/bin/logger 命令。logger                命令使用指定的优先级将消息写入系统日志。例如，下面的命令使用与 alert  对应的数字优先级写入消息 New script executed，这种优先级的消息应该始终得到记录：          

1	/usr/bin/logger -p 1 "New script executed"

                验证新命令的执行是一个好习惯，但与分析所有启动脚本的相对性能和每个脚本执行时间的长短等相比，用处没那么大。作为一种极其方便的实用工具，Bootchart 以图形化的格式提供这类信息。          
                Bootchart 原本是一个 shell 脚本，但最新版本 Bootchart 2 使用 C 编程语言重新编写了它，所以它可以提供更高性能，并减少应用程序本身对其所收集的数据的影响。使用 Bootchart 2 最新版本的方法是，获取当前版本的源代码，编译并安装应用程序，然后将它集成到用于引导系统的引导装载程序命令中。要编译和安装 Bootchart 2，必须在系统上安装以下内容：git 源代码控制系统、make 应用程序编译工具和 gcc C 编译器。然后可以完成以下步骤：          

•                         使用 git 命令克隆 Bootchart 2 的源代码库：                  
  

  1	git clone https://github.com/mmeeks/bootchart

  
  
  
  
•                   将目录更改为在前一步骤中创建的 bootchart 目录，并执行 make 命令编译 Bootchart 2 的各个部分。
•                   以 root 用户身份或通过 sudo 命令执行 make install                  命令，在默认位置安装不同的 Bootchart 2 应用程序及其文档。
•                         在目前正在使用的 bootloader 配置文件中 kernel 项的末尾处添加如下片段：                  
  

  1	initcall_debug printk.time=y quiet init=/sbin/bootchartd

  
  
  
                          如果使用的是 GRUB bootloader，那么您很可能要在 /boot/grub/menu.lst 文件的 boot stanza 中添加前面的文本片段。如果使用的是 GRUB2 bootloader，那么您很可能要在 /boot/grub/grub.conf 文件的 boot stanza  中添加前面的文本片段。系统上的 GRUB 配置文件是使用命令自动生成的，比如 grub-mkconfig 或 grub2-mkconfig，您应该将前面的文本片段添加到 /etc/default/grub 文件中指定的默认内核引导选项，然后重新生成真正的 bootloader 配置文件。                  
  

                下次重启系统时，Bootchart 2 会收集启动过程中每个阶段的相关数据，并采用 Portable Network Graphics                (PNG) 格式，以图形化的方式对这些数据进行汇总。汇总数据保存在 /var/log/bootchart.tgz 文件中。这些数据的相关图形化表示保存在 /var/log/bootchart.png 文件中。 是对启动过程的图形化表示的摘要。          
图 1.           Bootchart 的图形化启动表示摘要                在 Bootchart 2 的启动过程图形化视图上，顶部汇总了在系统上收集到的启动信息，包括启动过程所花费的总体时长。中部以图形化的方式展示所有启动进程（这里的 图 1 是一段摘要）。底部两个区域分别显示了进程的累计处理器使用情况和累计 I/O 使用情况。      
                 每次重启系统时，所有以前叫这些名称的文件都将被覆盖。如果试验性地修改系统在启动期间执行各个脚本的顺序，或者尝试优化它们的内容，或者同时执行这两个操作，那么您很可能希望保留来自多次系统启动的摘要 Bootchart 2 数据。
Bootchart 2 在其配置文件（/etc/bootchartd.conf）中提供了 CUSTOM_POST_CMD 变量。这个变量的作用是在 Bootchart 2 创建了它的数据和相关图形文件后，指定到要执行的脚本或其他应用程序的完整路径。清单 5 是一个示例脚本，通过使用该脚本，可使用 YYYY-MM-DD-HH-MM-HOSTNAME 格式的名称重新命名输出文件，并将它们保存在 /var/log/bootchart 目录中。      
清单 5.           对 Bootchart 输出文件进行惟一重命名的示例脚本        

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#!/bin/bash source /etc/bootchartd.conf HOST=$(hostname -s) if [ ! -d $(dirname $BOOTLOG_DEST)"/bootchart" ] ; then     mkdir $(dirname $BOOTLOG_DEST)"/bootchart" fi DATE=$(date +%Y-%m-%d-%H-%M) filebase="$DATE-$HOST" mv $BOOTLOG_DEST $(dirname $BOOTLOG_DEST)"/bootchart/"${filebase}".tgz" if [ "x$AUTO_RENDER" = "xyes" ] ; then     mv ${AUTO_RENDER_DIR}/bootchart.${AUTO_RENDER_FORMAT} \        $(dirname $BOOTLOG_DEST)"/bootchart/"${filebase}"."${AUTO_RENDER_FORMAT} fi

        Bootchart 2 适用于本文中提到的所有 Linux 系统启动机制，而且它可以非常直观地展示系统启动过程中每个步骤所花费的时间、处理器和 I/O。这有助于找出启动过程中能够进行优化的地方，从而最大程度地缩短系统启动时间。      
        总结              Linux 提供多种启动机制，其中一些很容易修改，而其他一些是可扩展的，但主要是针对速度而设计的。本文总结了三种最流行的 Linux        启动机制，重点讲述了它们在目标与实现方面的差异。不同的 Linux 发行版本可开箱即用地使用不同的启动机制，安装它们并进行试验并不难，您最终可以找到在性能、灵活性和可用性最能满足自己要求的启动机制。