从BIOS到GRUB

• 系统开机或者重启。

1. BIOS加电，自检（Power On Self Test -- POST）。BIOS执行内存地址为FFFF:0000H处的跳转指令，跳转到固化在ROM中的自检程序处，对系统硬件（包括内存）进行检查。
2. 读取主引导记录（MBR）。当BIOS检查到硬件正常并与CMOS中的设置相符后，按照CMOS中对启动设备的设置顺序检测可用的启动设备。BIOS将相应启动设备的第一个扇区（也就是MBR扇区）读入内存地址为0000:7C00H处。
3. 检查0000:7DFEH-0000:7DFFH（MBR的结束标志位）是否等于55AAH，若不等于则转去尝试其他启动设备，如果没有启动设备满足要求则显示"NO ROM BASIC"然后死机。
4. 当检测到有启动设备满足要求后，BIOS将控制权交给相应启动设备。启动设备的MBR将自己复制到0000:0600H处，然后继续执行。
5. 根据MBR中的引导代码，启动引导程序GRUB。

• 事实上，BIOS不仅检查0000:7DFEH-0000:7DFFH（MBR的结束标志位）是否等于55AAH，往往还对磁盘是否有写保护、主引导扇区中是否存在活动分区等进行检查。如果发现磁盘有写保护，则显示磁盘写保护出错信息；如果发现磁盘中不存在活动分区，则显示类似如下的信息“Remove disk or other media Press any key to restart”。

重要的唯一地址：主引导扇区MBR

主引导记录（Master Boot Record，缩写：MBR），又叫做主引导扇区，是[计算机开机后访问[硬盘时所必须要读取的首个扇区，它在硬盘上的三维地址为：

（柱面，磁头，扇区）＝（0，0，1）

在深入讨论主引导扇区内部结构的时候，有时也将其开头的446字节内容特指为“主引导记录”（MBR），其后是4个16字节的“磁盘分区表”（DPT），以及2字节的结束标志（55AA）。因此，在使用“主引导记录”（MBR）这个术语的时候，

需要根据具体情况判断其到底是指整个主引导扇区，还是主引导扇区的前446字节

我们这里就讲0-445字节，和446-512，分别对应标准MBR分区表，和可以引导标记符来代替，而可引导标记符为最后2字节55与AA，干脆就叫MBR分区表和55AA吧。硬盘0-512字节表结构见图。

启动代码

0-445字节完成MBR中的引导程序的加载后，引导程序开始检查分区表（446-509）的正确性。将控制权交给硬盘上的引导程序GNU GRUB

这里需要说明的是：

『 64个字节的硬盘分区表，（446-510）：由于每个分区信息需要16个字节，所以对于采用MBR型分区结构的硬盘，最多只能识别4个主要分区（Primary partition）』

现在已经搞清楚了结构，一起梳理一下流程吧！

1. BIOS加电自检（Power On Self Test -- POST）。BIOS执行内存地址为FFFF:0000H处的跳转指令，跳转到固化在ROM中的自检程序处，对系统硬件（包括内存）进行检查。（BIOS不仅检查0000:7DFEH-0000:7DFFH（MBR的结束标志位）是否等于55AAH，往往还对磁盘是否有写保护、主引导扇区中是否存在活动分区等进行检查。如果发现磁盘有写保护，则显示磁盘写保护出错信息；如果发现磁盘中不存在活动分区，则显示类似如下的信息“Remove disk or other media Press any key to restart”。）
2. 读取主引导记录（MBR）。当BIOS检查到硬件正常并与CMOS中的设置相符后，按照CMOS中对启动设备的设置顺序检测可用的启动设备。BIOS将相应启动设备的第一个扇区（也就是MBR扇区）读入内存地址为0000:7C00H处。
3. 检查0000:7DFEH-0000:7DFFH（MBR的结束标志位）是否等于55AAH，若不等于则转去尝试其他启动设备，如果没有启动设备满足要求则显示"NO ROM BASIC"然后死机。
4. 当检测到有启动设备满足要求后，BIOS将控制权交给相应启动设备。启动设备的MBR将自己复制到0000:0600H处，然后继续执行。
5. 根据MBR中的引导代码启动引导程序Grub。

「Windows的PBR认识FAT32和NTFS两种分区，找到分区根目录的bootmgr文件，加载、执行bootmgr。
bootmgr没了MBR和PBR的大小限制，可以做更多的事。它会加载并分析BCD启动项存储。而且bootmgr可以跨越磁盘读取文件了。所以无论你有几个磁盘，你在多少块磁盘上装了Windows，一个电脑只需要一个bootmgr就行了。bootmgr会去加载某磁盘某NTFS分区的\Windows\System32\WinLoad.exe，后面启动Windows的事就由WinLoad.exe来完成了。」

开机后，固化在ROM里的BIOS就会被加载到内存运行，BIOS自检完毕以后加载COMS的参数，通过COMS的参数，BIOS程序加载启动磁盘的MBR到内存里运行，运行MBR的引导代码，这段代码会查找活动分区（BIOS不认识活动分区，但这段代码认识活动分区）的位置，加载并执行活动分区的PBR（另一段引导程序），与MBR类似，PBR在运行后加载操作系统的引导程序到内存运行，例如Windows的bootmgr或Linux的GRUB。当引导程序运行后，操作系统内核就被加载运行，完成从BIOS程序中接手的引导流程。

到了这里，就不得不引出GRUB了，可是现代计算机的GPT分区呢？UEFI引导呢？是否也是如此流程呢？

现在我们知道了 BIOSGPT是如何启动GRUB的吧。

从UEFI到GRUB

BIOS到GRUB已经明确了。我们现在来看看 UEFI的启动。这是我最不想阐述的，因为UEFI功能很多，而且强大无比，以至于无法很快解释的清楚。先让我们读懂GPT分区吧。

全局唯一标识分区表（GPT）

在解释原生UEFI的引导动作时还需要理解GPT分区。全局唯一标识分区表（GUID Partition Table，缩写：GPT）是一个实体硬盘的分区表的结构布局的标准。它是可扩展固件接口（UEFI）标准（被Intel用于替代个人计算机的BIOS）的一部分，被用于替代BIOS系统中的一32bits来存储逻辑块地址和大小信息的主引导记录（MBR）分区表。对于那些扇区为512字节的磁盘，MBR分区表不支持容量大于2.2TB（2.2×10^12字节）的分区，既位置在磁盘的第一个逻辑扇区，LBA0的位置。一个逻辑扇区仅有512B（字节），分给MBR分区表的只有64B，由4个16B大小的分区，硬盘主分区数目不能超过4个，MBR分区表最大可寻址的存储空间只有2TB（2^32 * 512）

标准MBR结构如下：

（有些硬盘厂商制造了兼容mbr结构，容量较大的磁盘升级到4KB的扇区，这意味着MBR的有效容量上限提升到16 TiB，彻头彻尾的作弊啊！）

标准GPT结构如下：

如图可以看出：GPT分为以下几个部分：

• 保护性MBR： 处于位置LBA0,是在CPT分区表的开头，为了兼容性而存在的传统的MBR。一般情况下是没有引导代码，仅仅有一个被标识为未知的分区，当支持GPT分区表的操作系统检索到这个MBR后会自动忽略并跳到LBA1读取CGT分区表。
• GPT头：定义了硬盘的可控件和组成分区表的项的大小和数量，还记录了这块硬盘的GUID，记录了分区表头本身的位置和大小以及备份分区表头和分区表的位置和大小。
• 分区表：用于存储分区的信息。如（分区类型GUID，起始LBA，末尾LBA等）
• 分区：是物理磁盘的一部分，作用如同一个物理分隔单元。其基本信息存在分区表中。
• 分区表备份对分区表进行备份
• GPT头备份对GPT头进行备份。处于硬盘最后面

UEFI 与BIOS启动原理不同

GPT是基于UEFI的，因此BIOS是无法引导GPT磁盘里的操作系统的。但是GPT却可以兼容BIOS引导方式，在GPT分区表的最开头，出于兼容性BIOS引导，仍然存储了一份传统的MBR，用来防止不支持GPT的硬盘管理工具错误识别并破坏硬盘中的数据，这个MBR也叫做保护MBR。在支持从GPT启动的操作系统，这里也用于存储第一阶段的启动代码（这个会在GRUB中细谈）。在这个MBR中，只有一个标识为0xEE的分区，以此来表示这块硬盘使用GPT分区表。不能识别GPT硬盘的操作系统通常会识别出一个未知类型的分区，并且拒绝对硬盘进行操作，除非用户特别要求删除这个分区。这就避免了意外删除分区的危险。另外，能够识别GPT分区表的操作系统会检查保护MBR中的分区表，如果分区类型不是0xEE或者MBR分区表中有多个项，也会拒绝对硬盘进行操作。这样的预留就诞生了MBR/GPT混合分区表，使用MBR/GPT混合分区表的硬盘中，这部分存储了GPT分区表的一部分分区（通常是前四个分区），可以使不支持从GPT启动的操作系统从这个MBR启动，启动后只能操作MBR分区表中的分区。如Boot Camp就是使用这种方式启动Windows。（UEFI 的计算机，其固件具有 BIOS 兼容功能，并且你打算一直使用这项兼容功能，在启动过程中，你的计算机看起来就是基于 BIOS 的。你只需要像 BIOS 启动一样进行所需操作即可，强烈建议不要混合使用原生 UEFI 启动和 BIOS 兼容启动，尤其不要在同一块磁盘上混用。）

不能把 BIOS 启动的原理直接套用到原生 UEFI 启动上，许多厂商的UEFI固件实现了某种 BIOS 兼容模式，称为 CSM。许多 UEFI 固件可以像 BIOS 固件一样启动系统，它们可以查找磁盘上的 MBR，然后从 MBR 中执行启动装载程序，接着将后续工作完全交给启动装载程序。

有时候，其他人误将此功能称为“禁用 UEFI”，其实系统固件是无法“禁用”的，看了这篇文章你就不要采用这种荒谬的说法了。严禁的说应该是以“兼容BIOS 风格”启动系统，而不是采用原生 UEFI 方式启动系统。

原生 UEFI 方式启动系统:

UEFI-CSM（BIOS兼容模式）：

UEFI遍历磁盘上的每个 EFI 系统分区（按照磁盘上的分区顺序）。在 ESP 内，固件将查找位于特定位置的具有特定名称的文件。查找的是 \EFI\BOOT\BOOT{计算机类型简称}.EFI，其中，“x64”是 x86-64 PC 的“计算机类型简称”。

文件名：

BOOTIA32.EFI (x86-32)、BOOTIA64.EFI (Itanium)、BOOTARM.EFI、BOOTAA64.EFI

「EFI系统分区（英语：EFI system partition，简写为ESP），是一个FAT或FAT32格式的磁盘分区，但是其分区标识是EF (十六进制) 而非常规的0E或0C。UEFI固件可从ESP加载EFI启动程式或者EFI应用程式。」

固件将执行找到的第一个有效文件，也就是在UEFI系统启动后，GUID分区表就会被识别，之后EFI系统就会通过.efi文件启动Boot Loader程序加载操作系统内核。

BIOS和UEFI对比：

终于到了GRUB

不管是UEFI 还是 BIOS开始，它的唯一目的是找到可引导磁盘，去加载引导程序GRUB。

引导程序的任务就是操作系统，也就是Linux的基本启动Kernel，然后指向Init

还没写完先把导引图放好。

当前绝大多数的Linux发行版都已采用systemd代替原来的System V与 init，干脆总结一下吧。

systemd是Linux电脑操作系统之下的一套中央化系统及设置管理程序（init），包括有守护进程、程序库以及应用软件，由Lennart Poettering带头开发。其开发目标是提供更优秀的框架以表示系统服务间的依赖关系，并依此实现系统初始化时服务的并行启动，同时达到降低Shell的系统开销的效果，最终代替现在常用的System V与BSD风格init程序。

这里先谈一下历史，从init，到System V，在到systemd。

历史怎么谈，太难了。

1969年就这样到了1991年，于是有了Linux 操作系统，在保留着Unix引导风格的情况下，启动了 BIOS，接下来进入 boot loader，由 bootloader 载入内核，进行内核初始化。内核初始化的最后一步就是启动 pid 为 1 的 init 进程。

这个进程是系统的第一个进程。它负责产生其他所有用户进程。

init 以守护进程方式存在，是所有其他进程的祖先。init 进程非常独特，能够完成其他进程无法完成的任务。

Init 系统能够定义、管理和控制 init 进程的行为。它负责组织和运行许多独立的或相关的始化工作(因此被称为 init 系统)，从而让计算机系统进入某种用户预订的运行模式。

仅仅将内核运行起来是毫无实际用途的，必须由 init 系统将系统代入可操作状态。比如启动外壳 shell 后，便有了人机交互，这样就可以让计算机执行一些预订程序完成有实际意义的任务。或者启动 X 图形系统以便提供更佳的人机界面，更加高效的完成任务。这里，字符界面的 shell 或者 X 系统都是一种预设的运行模式。

大多数 Linux 发行版的 init 系统是和 System V 相兼容的，被称为 sysvinit。这是人们最熟悉的 init 系统。

后来一些发行版如 Slackware一直采用 BSD 风格 Init 系统，再后来Debian/Ubuntu 和 RHEL 采用 upstart 替代了传统的 sysvinit。而 Fedora版本15又开始使用了一个被称为 systemd 的新 init 系统取代了upstart。不同的发行版采用了不同的 init 实现，伟大的pid 1，从无到有，从0到1，从1969到2019。duang的一声历史谈完了。

Sysvinit（system V ） 概况

UNIX System V是Unix操作系统众多版本中的一支。它最初由AT&T开发，在1983年第一次发布，因此也被称为AT&T System V。一共发行了4个System V的主要版本：版本1、2、3和4。System V Release 4，或者称为SVR4，是最成功的版本，成为一些UNIX共同特性的源头，例如“SysV 初始化脚本”（/etc/init.d）

而sysvinit 就是 system V 风格的 init 系统，顾名思义，它源于 System V 系列 UNIX。它提供了比 BSD 风格 init 系统更高的灵活性。是已经风行了几十年的 UNIX init 系统，一直被各类 Linux 发行版所采用。在 Linux 主要应用于服务器和 PC 机的时代，SysVinit 运行非常良好，概念简单清晰。

但是它依赖于 Shell的脚本，这就决定了它的最大弱点：启动太慢。

在很少重新启动的 Server 上，这个缺点并不重要。而当 Linux 被应用到移动终端设备的时候，启动慢就成了一个大问题。为了更快地启动，人们开始改进 sysvinit，先后出现了 upstart 和 systemd 这两个主要的新一代 init 系统。

Upstart 已经开发了 8 年多，在不少系统中已经替换 sysvinit，而Systemd 出现较晚，但发展更快，Debian Centos都已经采用Systemd取代 upstart。

inittab在RHEL 7中就已消失了，但是Centos还是保留了inittab，让我们看看里面说了什么。

-bash-4.2$ cat /etc/inittab

# inittab is no longer used when using systemd.
（systemd不再使用inittab）
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
（在此处添加配置不会对您的系统产生任何影响）
#
# Ctrl-Alt-Delete is handled by /usr/lib/systemd/system/ctrl-alt-del.target
（Ctrl-Alt-Delete由/usr/lib/systemd/system/ctrl-alt-del.target处理）
#
# systemd uses 'targets' instead of runlevels. By default, there are two main targets:
（systemd使用“targets”而不是运行级别。 默认情况下，有两个主要targets：）
#
# multi-user.target: analogous to runlevel 3
（multi-user.target：类似于运行级别3）
# graphical.target: analogous to runlevel 5
（graphic.target：类似于运行级别5）
#
# To view current default target, run:
# systemctl get-default
（要查看当前的默认目标，请运行：systemctl get-default）
#
# To set a default target, run:
# systemctl set-default TARGET.target
（设置默认target,运行：systemctl set-default TARGET.target）
#

这里重点

第一、systemd代替了sysvinit

第二、runlevel（运行级别）被 TARGET（目标）所替换

第三、提供了如何查看默认和修改运行target

systemctl get-default
systemctl set-default TARGET.target

运行级别

为了搞明白target，那就需要先搞明白运行级别

在Sysvinit 用术语 runlevel 来定义"预订的运行模式"。

RHEL5以前的玩家，都知道Sysvinit 会检查 '/etc/inittab' 文件中是否含有 'initdefault' 项。

这告诉 init 系统是否有一个默认运行模式。如果没有默认的运行模式，那么用户将进入系统控制台，手动决定进入何种运行模式。

sysvinit 中运行模式描述了系统各种预订的运行模式。通常会有 8 种运行模式，即运行模式 0 到 6 和 S 或者 s。

每种 Linux 发行版对运行模式的定义都不太一样。但 0，1，6 却得到了大家的一致赞同：

• 0 关机
• 1 单用户模式
• 6 重启

通常在 /etc/inittab 文件中定义了各种运行模式的工作范围。比如 RedHat 定义了 runlevel 3 和 5。运行模式 3 将系统初始化为字符界面的 shell 模式；运行模式 5 将系统初始化为 GUI 模式。无论是命令行界面还是 GUI，运行模式 3 和 5 相对于其他运行模式而言都是完整的正式的运行状态，计算机可以完成用户需要的任务。而模式 1，S 等往往用于系统故障之后的排错和恢复。

很显然，这些不同的运行模式下系统需要初始化运行的进程和需要进行的初始化准备都是不同的。比如运行模式 3 不需要启动 X 系统。用户只需要指定需要进入哪种模式，sysvinit 将负责执行所有该模式所必须的初始化工作。

sysvinit 运行顺序

Sysvinit 巧妙地用脚本，文件命名规则和软链接来实现不同的 runlevel。首先，sysvinit 需要读取/etc/inittab 文件。分析这个文件的内容，它获得以下一些配置信息：

• 系统需要进入的 runlevel
• 捕获组合键的定义
• 定义电源 fail/restore 脚本
• 启动 getty 和虚拟控制台

得到配置信息后，sysvinit 顺序地执行以下这些步骤，从而将系统初始化为预订的 runlevel X。

• /etc/rc.d/rc.sysinit
• /etc/rc.d/rc 和/etc/rc.d/rcX.d/ (X 代表运行级别 0-6)
• /etc/rc.d/rc.local
• X Display Manager（如果需要的话）

首先，运行 rc.sysinit 以便执行一些重要的系统初始化任务。在 RedHat 公司的 RHEL5 中(RHEL6 已经使用 upstart 了)，rc.sysinit 主要完成以下这些工作。

• 激活 udev 和 selinux
• 设置定义在/etc/sysctl.conf 中的内核参数
• 设置系统时钟
• 加载 keymaps
• 使能交换分区
• 设置主机名(hostname)
• 根分区检查和 remount
• 激活 RAID 和 LVM 设备
• 开启磁盘配额
• 检查并挂载所有文件系统
• 清除过期的 locks 和 PID 文件

完成了以上这些工作之后，sysvinit 开始运行/etc/rc.d/rc 脚本。根据不同的 runlevel，rc 脚本将打开对应该 runlevel 的 rcX.d 目录(X 就是 runlevel)，找到并运行存放在该目录下的所有启动脚本。每个 runlevel X 都有一个这样的目录，目录名为/etc/rc.d/rcX.d。

在这些目录下存放着很多不同的脚本。文件名以 S 开头的脚本就是启动时应该运行的脚本，S 后面跟的数字定义了这些脚本的执行顺序。在/etc/rc.d/rcX.d 目录下的脚本其实都是一些软链接文件，真实的脚本文件存放在/etc/init.d 目录下。

如下我的Debian 10 所示：

rc5.d 目录下的脚本

root@thinkpad:/etc/initramfs-tools# ll /etc/rc5.d/
总用量 4
lrwxrwxrwx 1 root root  27 11月  4 15:10 K02speech-dispatcher -> ../init.d/speech-dispatcher
-rw-r--r-- 1 root root 677 2月  15  2019 README
lrwxrwxrwx 1 root root  26 11月  4 11:06 S01console-setup.sh -> ../init.d/console-setup.sh
lrwxrwxrwx 1 root root  18 11月  7 10:32 S02minidlna -> ../init.d/minidlna
lrwxrwxrwx 1 root root  16 11月  4 15:42 S02mysqld -> ../init.d/mysqld
lrwxrwxrwx 1 root root  20 11月  4 17:57 S02php-fpm-73 -> ../init.d/php-fpm-73
lrwxrwxrwx 1 root root  17 11月  4 15:10 S02rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root  14 11月  4 15:10 S02sudo -> ../init.d/sudo
lrwxrwxrwx 1 root root  29 11月  4 15:10 S02unattended-upgrades -> ../init.d/unattended-upgrades
lrwxrwxrwx 1 root root  17 11月  4 15:10 S03anacron -> ../init.d/anacron
lrwxrwxrwx 1 root root  24 11月  5 09:47 S03cgroupfs-mount -> ../init.d/cgroupfs-mount
lrwxrwxrwx 1 root root  14 11月  4 15:10 S03cron -> ../init.d/cron
lrwxrwxrwx 1 root root  14 11月  4 15:10 S03dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root  18 11月  5 13:13 S03fail2ban -> ../init.d/fail2ban
lrwxrwxrwx 1 root root  13 11月  4 15:10 S03ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root  16 11月  5 13:12 S03xl2tpd -> ../init.d/xl2tpd
lrwxrwxrwx 1 root root  22 11月  4 15:10 S04avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root  19 11月  4 15:10 S04bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root  16 11月  5 09:47 S04docker -> ../init.d/docker
lrwxrwxrwx 1 root root  25 11月  4 15:10 S04network-manager -> ../init.d/network-manager
lrwxrwxrwx 1 root root  14 11月  4 15:10 S05gdm3 -> ../init.d/gdm3
lrwxrwxrwx 1 root root  15 11月  4 15:10 S05saned -> ../init.d/saned
lrwxrwxrwx 1 root root  12 11月  4 15:10 S06bt -> ../init.d/bt
lrwxrwxrwx 1 root root  15 11月  4 15:10 S06httpd -> ../init.d/httpd
lrwxrwxrwx 1 root root  18 11月  4 15:10 S06plymouth -> ../init.d/plymouth
lrwxrwxrwx 1 root root  19 11月  4 16:27 S06pure-ftpd -> ../init.d/pure-ftpd
root@thinkpad:/etc/initramfs-tools# 

当所有的初始化脚本执行完毕。Sysvinit 运行/etc/rc.d/rc.local 脚本。这里有人说了，不是Debian 10已经淘汰sysvinit了吗？是的，没错，但是别忘了systemd没有了inittab，不代表他不兼容rcX.d，

这里需要注意：

Debian的systemd

/etc/init.d/
/etc/rcX.d
/etc/rc.local(默认没有)

Centos的rc.d

/etc/rc.d/
/etc/rc.d/rcX.d
/etc/rc.local 指向 ----> /etc/rc.d/rc.local

rc.local 是 Linux 留给用户进行个性化设置的地方。您可以把自己私人想设置和启动的东西放到这里，一台 Linux Server 的用户一般不止一个，所以才有这样的考虑。

Sysvinit 和系统关闭

Sysvinit 不仅需要负责初始化系统，还需要负责关闭系统。在系统关闭时，为了保证数据的一致性，需要小心地按顺序进行结束和清理工作。

比如应该先停止对文件系统有读写操作的服务，然后再 umount 文件系统。否则数据就会丢失。

这种顺序的控制这也是依靠/etc/rc.d/rcX.d/目录下所有脚本的命名规则来控制的，在该目录下所有以 K 开头的脚本都将在关闭系统时调用，字母 K 之后的数字定义了它们的执行顺序。

这些脚本负责安全地停止服务或者其他的关闭工作。

Sysvinit 的管理和控制功能

此外，在系统启动之后，管理员还需要对已经启动的进程进行管理和控制。原始的 sysvinit 软件包包含了一系列的控制启动，运行和关闭所有其他程序的工具。由于systemd的取代，这里很多命令已经被systemctl接管了。

halt
停止系统。

init
这个就是 sysvinit 本身的 init 进程实体，以 pid1 身份运行，是所有用户进程的父进程。最主要的作用是在启动过程中使用/etc/inittab 文件创建进程。

killall5
就是 SystemV 的 killall 命令。向除自己的会话(session)进程之外的其它进程发出信号，所以不能杀死当前使用的 shell。

last
回溯/var/log/wtmp 文件(或者-f 选项指定的文件)，显示自从这个文件建立以来，所有用户的登录情况。

lastb
作用和 last 差不多，默认情况下使用/var/log/btmp 文件，显示所有失败登录企图。

mesg
控制其它用户对用户终端的访问。

pidof
找出程序的进程识别号(pid)，输出到标准输出设备。

poweroff
等于 shutdown -h –p，或者 telinit 0。关闭系统并切断电源。

reboot
等于 shutdown –r 或者 telinit 6。重启系统。

runlevel
读取系统的登录记录文件(一般是/var/run/utmp)把以前和当前的系统运行级输出到标准输出设备。

shutdown
以一种安全的方式终止系统，所有正在登录的用户都会收到系统将要终止通知，并且不准新的登录。

sulogin
当系统进入单用户模式时，被 init 调用。当接收到启动加载程序传递的-b 选项时，init 也会调用 sulogin。

telinit
实际是 init 的一个连接，用来向 init 传送单字符参数和信号。

utmpdump
以一种用户友好的格式向标准输出设备显示/var/run/utmp 文件的内容。

wall
向所有有信息权限的登录用户发送消息。

不同的 Linux 发行版在这些 sysvinit 的基本工具基础上又开发了一些辅助工具用来简化 init 系统的管理工作。比如 RedHat 的 RHEL 在 sysvinit 的基础上开发了 initscripts 软件包，包含了大量的启动脚本 (如 rc.sysinit) ，还提供了 service，chkconfig 等命令行工具，甚至一套图形化界面来管理 init 系统。其他的 Linux 发行版也有各自的 initscript 或其他名字的 init 软件包来简化 sysvinit 的管理。

只要您理解了 sysvinit 的机制，在一个最简的仅有 sysvinit 的系统下，您也可以直接调用脚本启动和停止服务，手动创建 inittab 和创建软连接来完成这些任务。因此理解 sysvinit 的基本原理和命令是最重要的。您甚至也可以开发自己的一套管理工具。

Sysvinit 的小结

Sysvinit 的优点是概念简单。Service 开发人员只需要编写启动和停止脚本，概念非常清楚；将 service 添加/删除到某个 runlevel 时，只需要执行一些创建/删除软连接文件的基本操作；这些都不需要学习额外的知识或特殊的定义语法

(UpStart 和 Systemd 都需要用户学习新的定义系统初始化行为的语言)。

sysvinit 的另一个重要优点是确定的执行顺序：

脚本严格按照启动数字的大小顺序执行，一个执行完毕再执行下一个，这非常有益于错误排查。UpStart 和 systemd 支持并发启动，导致没有人可以确定地了解具体的启动顺序，排错不易。

但是串行地执行脚本导致 sysvinit 运行效率较慢，在新的 IT 环境下，启动快慢成为一个重要问题。此外动态设备加载等 Linux 新特性也暴露出 sysvinit 设计的一些问题。针对这些问题，人们开始想办法改进 sysvinit，以便加快启动时间，并解决 sysvinit 自身的设计问题。这就引来了，Upstart，第一个被广泛应用的新一代 init 系统（嘿嘿，真没活多久）。

Upstart 简介

开发 Upstart 的缘由

大约在 2006 年或者更早的时候， Ubuntu 开发人员试图将 Linux 安装在笔记本电脑上。在这期间技术人员发现经典的 sysvinit 存在一些问题：它不适合笔记本环境。这促使程序员 Scott James Remnant 着手开发 upstart。

当 Linux 内核进入 2.6 时代时，内核功能有了很多新的更新。新特性使得 Linux 不仅是一款优秀的服务器操作系统，也可以被用于桌面系统，甚至嵌入式设备。桌面系统或便携式设备的一个特点是经常重启，而且要频繁地使用硬件热插拔技术。在现代计算机系统中，硬件繁多、接口有限，人们并非将所有设备都始终连接在计算机上，比如 U 盘平时并不连接电脑，使用时才插入 USB 插口。因此，当系统上电启动时，一些外设可能并没有连接。而是在启动后当需要的时候才连接这些设备。在 2.6 内核支持下，一旦新外设连接到系统，内核便可以自动实时地发现它们，并初始化这些设备，进而使用它们。这为便携式设备用户提供了很大的灵活性。

可是这些特性为 sysvinit 带来了一些挑战。当系统初始化时，需要被初始化的设备并没有连接到系统上；比如打印机。为了管理打印任务，系统需要启动 CUPS 等服务，而如果打印机没有接入系统的情况下，启动这些服务就是一种浪费。Sysvinit 没有办法处理这类需求，它必须一次性把所有可能用到的服务都启动起来，即使打印机并没有连接到系统，CUPS 服务也必须启动。

还有网络共享盘的挂载问题。在/etc/fstab 中，可以指定系统自动挂载一个网络盘，比如 NFS，或者 iSCSI 设备。在本文的第一部分 sysvinit 的简介中可以看到，sysvinit 分析/etc/fstab 挂载文件系统这个步骤是在网络启动之前。可是如果网络没有启动，NFS 或者 iSCSI 都不可访问，当然也无法进行挂载操作。Sysvinit 采用 netdev 的方式来解决这个问题，即/etc/fstab 发现 netdev 属性挂载点的时候，不尝试挂载它，在网络初始化并使能之后，还有一个专门的 netfs 服务来挂载所有这些网络盘。这是一个不得已的补救方法，给管理员带来不便。部分新手管理员甚至从来也没有听说过 netdev 选项，因此经常成为系统管理的一个陷阱。

针对以上种种情况，Ubuntu 开发人员在评估了当时的几个可选 init 系统之后，决定重新设计和开发一个全新的 init 系统，即 UpStart。UpStart 基于事件机制，比如 U 盘插入 USB 接口后，udev 得到内核通知，发现该设备，这就是一个新的事件。UpStart 在感知到该事件之后触发相应的等待任务，比如处理/etc/fstab 中存在的挂载点。采用这种事件驱动的模式，upstart 完美地解决了即插即用设备带来的新问题。

采用事件驱动机制也带来了一些其它有益的变化，比如加快了系统启动时间。

sysvinit 运行时是同步阻塞的。一个脚本运行的时候，后续脚本必须等待。这意味着所有的初始化步骤都是串行执行的，而实际上很多服务彼此并不相关，完全可以并行启动，从而减小系统的启动时间。在 Linux 大量应用于服务器的时代，系统启动时间也许还不那么重要；然而对于桌面系统和便携式设备，启动时间的长短对用户体验影响很大。此外云计算等新的 Server 端技术也往往需要单个设备可以更加快速地启动。

UpStart 满足了这些需求，目前不仅桌面系统 Ubuntu 采用了 UpStart，甚至企业级服务器级的 RHEL 也默认采用 UpStart 来替换 sysvinit 作为 init 系统。

Upstart 的特点

UpStart 解决了之前提到的 sysvinit 的缺点。采用事件驱动模型，UpStart 可以：

• 更快地启动系统
• 当新硬件被发现时动态启动服务
• 硬件被拔除时动态停止服务

这些特点使得 UpStart 可以很好地应用在桌面或者便携式系统中，处理这些系统中的动态硬件插拔特性。

Upstart 小结

可以看到，UpStart 的设计比 SysVInit 更加先进。多数 Linux 发行版上已经不再使用 SysVInit，一部分发行版采用了 UpStart，比如 Ubuntu；而另外一些比如 Fedora，采用了一种被称为 systemd 的 init 系统。Systemd 出现的比 UpStart 更晚，但发展迅速，虽然 UpStart 也还在积极开发并被越来越多地应用，但 systemd 却更优秀。

https://wiki.debian.org/Debate/initsystem/

这是 Debian 的官方 Wiki 页面，专门用来做 init system 的辩论。分级页面中有各个init的优劣对比

http://blog.jorgenschaefer.de/2014/07/why-systemd.html

Systemd 的作者给出的比较

找时间在翻译吧

总之Upstart现在已成过去，尽在PAD PHONE等老旧设备中还在使用。

Systemd 的简介和特点

Systemd 是 Linux 系统中最新的初始化系统（init），它主要的设计目标是克服 sysvinit 固有的缺点，提高系统的启动速度。Systemd 的很多概念来源于苹果 Mac OS 操作系统上的 launchd，不过 launchd 专用于苹果系统，因此长期未能获得应有的广泛关注。Systemd 借鉴了很多 launchd 的思想，它的重要特性如下：

更快的启动速度

Systemd 提供了比 UpStart 更激进的并行启动能力，采用了 socket / D-Bus activation 等技术启动服务。一个显而易见的结果就是：更快的启动速度。

为了减少系统启动时间，systemd 的目标是：

• 尽可能启动更少的进程
• 尽可能将更多进程并行启动

启动挂载点和自动挂载的管理

传统的 Linux 系统中，用户可以用/etc/fstab 文件来维护固定的文件系统挂载点。这些挂载点在系统启动过程中被自动挂载，一旦启动过程结束，这些挂载点就会确保存在。这些挂载点都是对系统运行至关重要的文件系统，比如 HOME 目录。和 sysvinit 一样，Systemd 管理这些挂载点，以便能够在系统启动时自动挂载它们。Systemd 还兼容/etc/fstab 文件，您可以继续使用该文件管理挂载点。

有时候用户还需要动态挂载点，比如打算访问 DVD 内容时，才临时执行挂载以便访问其中的内容，而不访问光盘时该挂载点被取消(umount)，以便节约资源。传统地，人们依赖 autofs 服务来实现这种功能。

Systemd 内建了自动挂载服务，无需另外安装 autofs 服务，可以直接使用 systemd 提供的自动挂载管理能力来实现 autofs 的功能。

实现事务性依赖关系管理

系统启动过程是由很多的独立工作共同组成的，这些工作之间可能存在依赖关系，比如挂载一个 NFS 文件系统必须依赖网络能够正常工作。Systemd 虽然能够最大限度地并发执行很多有依赖关系的工作，但是类似"挂载 NFS"和"启动网络"这样的工作还是存在天生的先后依赖关系，无法并发执行。对于这些任务，systemd 维护一个"事务一致性"的概念，保证所有相关的服务都可以正常启动而不会出现互相依赖，以至于死锁的情况。

能够对系统进行快照和恢复

systemd 支持按需启动，因此系统的运行状态是动态变化的，人们无法准确地知道系统当前运行了哪些服务。Systemd 快照提供了一种将当前系统运行状态保存并恢复的能力。

比如系统当前正运行服务 A 和 B，可以用 systemd 命令行对当前系统运行状况创建快照。然后将进程 A 停止，或者做其他的任意的对系统的改变，比如启动新的进程 C。在这些改变之后，运行 systemd 的快照恢复命令，就可立即将系统恢复到快照时刻的状态，即只有服务 A，B 在运行。一个可能的应用场景是调试：比如服务器出现一些异常，为了调试用户将当前状态保存为快照，然后可以进行任意的操作，比如停止服务等等。等调试结束，恢复快照即可。

这个快照功能目前在 systemd 中并不完善，似乎开发人员也没有特别关注它，因此有报告指出它还存在一些使用上的问题，使用时尚需慎重。

日志服务

systemd 自带日志服务 journald，该日志服务的设计初衷是克服现有的 syslog 服务的缺点。比如：

• syslog 不安全，消息的内容无法验证。每一个本地进程都可以声称自己是 Apache PID 4711，而 syslog 也就相信并保存到磁盘上。
• 数据没有严格的格式，非常随意。自动化的日志分析器需要分析人类语言字符串来识别消息。一方面此类分析困难低效；此外日志格式的变化会导致分析代码需要更新甚至重写。

Systemd Journal 用二进制格式保存所有日志信息，用户使用 journalctl 命令来查看日志信息。无需自己编写复杂脆弱的字符串分析处理程序。

Systemd Journal 的优点如下：

• 简单性：代码少，依赖少，抽象开销最小。
• 零维护：日志是除错和监控系统的核心功能，因此它自己不能再产生问题。举例说，自动管理磁盘空间，避免由于日志的不断产生而将磁盘空间耗尽。
• 移植性：日志 文件应该在所有类型的 Linux 系统上可用，无论它使用的何种 CPU 或者字节序。
• 性能：添加和浏览 日志 非常快。
• 最小资源占用：日志 数据文件需要较小。
• 统一化：各种不同的日志存储技术应该统一起来，将所有的可记录事件保存在同一个数据存储中。所以日志内容的全局上下文都会被保存并且可供日后查询。例如一条固件记录后通常会跟随一条内核记录，最终还会有一条用户态记录。重要的是当保存到硬盘上时这三者之间的关系不会丢失。Syslog 将不同的信息保存到不同的文件中，分析的时候很难确定哪些条目是相关的。
• 扩展性：日志的适用范围很广，从嵌入式设备到超级计算机集群都可以满足需求。
• 安全性：日志 文件是可以验证的，让无法检测的修改不再可能。

Systemd 的基本概念

单元的概念

系统初始化需要做的事情非常多。需要启动后台服务，比如启动 SSHD 服务；需要做配置工作，比如挂载文件系统。这个过程中的每一步都被 systemd 抽象为一个配置单元，即 unit。可以认为一个服务是一个配置单元；一个挂载点是一个配置单元；一个交换分区的配置是一个配置单元；等等。systemd 将配置单元归纳为以下一些不同的类型。

• service ：代表一个后台服务进程，比如 mysqld。这是最常用的一类。
• socket ：此类配置单元封装系统和互联网中的一个 套接字 。当下，systemd 支持流式、数据报和连续包的 AF_INET、AF_INET6、AF_UNIX socket 。每一个套接字配置单元都有一个相应的服务配置单元 。相应的服务在第一个"连接"进入套接字时就会启动(例如：nscd.socket 在有新连接后便启动 nscd.service)。
• device ：此类配置单元封装一个存在于 Linux 设备树中的设备。每一个使用 udev 规则标记的设备都将会在 systemd 中作为一个设备配置单元出现。
• mount ：此类配置单元封装文件系统结构层次中的一个挂载点。Systemd 将对这个挂载点进行监控和管理。比如可以在启动时自动将其挂载；可以在某些条件下自动卸载。Systemd 会将/etc/fstab 中的条目都转换为挂载点，并在开机时处理。
• automount ：此类配置单元封装系统结构层次中的一个自挂载点。每一个自挂载配置单元对应一个挂载配置单元 ，当该自动挂载点被访问时，systemd 执行挂载点中定义的挂载行为。
• swap: 和挂载配置单元类似，交换配置单元用来管理交换分区。用户可以用交换配置单元来定义系统中的交换分区，可以让这些交换分区在启动时被激活。
• target ：此类配置单元为其他配置单元进行逻辑分组。它们本身实际上并不做什么，只是引用其他配置单元而已。这样便可以对配置单元做一个统一的控制。这样就可以实现大家都已经非常熟悉的运行级别概念。比如想让系统进入图形化模式，需要运行许多服务和配置命令，这些操作都由一个个的配置单元表示，将所有这些配置单元组合为一个目标(target)，就表示需要将这些配置单元全部执行一遍以便进入目标所代表的系统运行状态。 (例如：multi-user.target 相当于在传统使用 SysV 的系统中运行级别 5)
• timer：定时器配置单元用来定时触发用户定义的操作，这类配置单元取代了 atd、crond 等传统的定时服务。
• snapshot ：与 target 配置单元相似，快照是一组配置单元。它保存了系统当前的运行状态。

每个配置单元都有一个对应的配置文件，系统管理员的任务就是编写和维护这些不同的配置文件，比如一个 MySQL 服务对应一个 mysql.service 文件。这种配置文件的语法非常简单，用户不需要再编写和维护复杂的系统 5 脚本了。

依赖关系

虽然 systemd 将大量的启动工作解除了依赖，使得它们可以并发启动。但还是存在有些任务，它们之间存在天生的依赖，不能用"套接字激活"(socket activation)、D-Bus activation 和 autofs 三大方法来解除依赖（三大方法详情见后续描述）。比如：挂载必须等待挂载点在文件系统中被创建；挂载也必须等待相应的物理设备就绪。为了解决这类依赖问题，systemd 的配置单元之间可以彼此定义依赖关系。

Systemd 用配置单元定义文件中的关键字来描述配置单元之间的依赖关系。比如：unit A 依赖 unit B，可以在 unit B 的定义中用"require A"来表示。这样 systemd 就会保证先启动 A 再启动 B。

Systemd 事务

Systemd 能保证事务完整性。Systemd 的事务概念和数据库中的有所不同，主要是为了保证多个依赖的配置单元之间没有环形引用。比如 unit A、B、C，假如它们的依赖关系为:

图 4, Unit 的循环依赖

存在循环依赖，那么 systemd 将无法启动任意一个服务。此时 systemd 将会尝试解决这个问题，因为配置单元之间的依赖关系有两种：required 是强依赖；want 则是弱依赖，systemd 将去掉 wants 关键字指定的依赖看看是否能打破循环。如果无法修复，systemd 会报错。

Systemd 能够自动检测和修复这类配置错误，极大地减轻了管理员的排错负担。

Target 和运行级别

systemd 用目标（target）替代了运行级别的概念，提供了更大的灵活性，如您可以继承一个已有的目标，并添加其它服务，来创建自己的目标。下表列举了 systemd 下的目标和常见 runlevel 的对应关系：

Sysvinit 运行级别和 systemd 目标的对应表

Sysvinit 运行级别	Systemd 目标	备注
0	runlevel0.target, poweroff.target	关闭系统。
1, s, single	runlevel1.target, rescue.target	单用户模式。
2, 4	runlevel2.target, runlevel4.target, multi-user.target	用户定义/域特定运行级别。默认等同于 3。
3	runlevel3.target, multi-user.target	多用户，非图形化。用户可以通过多个控制台或网络登录。
5	runlevel5.target, graphical.target	多用户，图形化。通常为所有运行级别 3 的服务外加图形化登录。
6	runlevel6.target, reboot.target	重启
emergency	emergency.target	紧急 Shell

Systemd 的并发启动原理

如前所述，在 Systemd 中，所有的服务都并发启动，比如 Avahi、D-Bus、livirtd、X11、HAL 可以同时启动。乍一看，这似乎有点儿问题，比如 Avahi 需要 syslog 的服务，Avahi 和 syslog 同时启动，假设 Avahi 的启动比较快，所以 syslog 还没有准备好，可是 Avahi 又需要记录日志，这岂不是会出现问题？

Systemd 的开发人员仔细研究了服务之间相互依赖的本质问题，发现所谓依赖可以分为三个具体的类型，而每一个类型实际上都可以通过相应的技术解除依赖关系。

并发启动原理之一：解决 socket 依赖

绝大多数的服务依赖是套接字依赖。比如服务 A 通过一个套接字端口 S1 提供自己的服务，其他的服务如果需要服务 A，则需要连接 S1。因此如果服务 A 尚未启动，S1 就不存在，其他的服务就会得到启动错误。所以传统地，人们需要先启动服务 A，等待它进入就绪状态，再启动其他需要它的服务。Systemd 认为，只要我们预先把 S1 建立好，那么其他所有的服务就可以同时启动而无需等待服务 A 来创建 S1 了。如果服务 A 尚未启动，那么其他进程向 S1 发送的服务请求实际上会被 Linux 操作系统缓存，其他进程会在这个请求的地方等待。一旦服务 A 启动就绪，就可以立即处理缓存的请求，一切都开始正常运行。

那么服务如何使用由 init 进程创建的套接字呢？

Linux 操作系统有一个特性，当进程调用 fork 或者 exec 创建子进程之后，所有在父进程中被打开的文件句柄 (file descriptor) 都被子进程所继承。套接字也是一种文件句柄，进程 A 可以创建一个套接字，此后当进程 A 调用 exec 启动一个新的子进程时，只要确保该套接字的 close_on_exec 标志位被清空，那么新的子进程就可以继承这个套接字。子进程看到的套接字和父进程创建的套接字是同一个系统套接字，就仿佛这个套接字是子进程自己创建的一样，没有任何区别。

这个特性以前被一个叫做 inetd 的系统服务所利用。Inetd 进程会负责监控一些常用套接字端口，比如 Telnet，当该端口有连接请求时，inetd 才启动 telnetd 进程，并把有连接的套接字传递给新的 telnetd 进程进行处理。这样，当系统没有 telnet 客户端连接时，就不需要启动 telnetd 进程。Inetd 可以代理很多的网络服务，这样就可以节约很多的系统负载和内存资源，只有当有真正的连接请求时才启动相应服务，并把套接字传递给相应的服务进程。

和 inetd 类似，systemd 是所有其他进程的父进程，它可以先建立所有需要的套接字，然后在调用 exec 的时候将该套接字传递给新的服务进程，而新进程直接使用该套接字进行服务即可。

并发启动原理之二：解决 D-Bus 依赖

D-Bus 支持所谓"bus activation"功能。如果服务 A 需要使用服务 B 的 D-Bus 服务，而服务 B 并没有运行，则 D-Bus 可以在服务 A 请求服务 B 的 D-Bus 时自动启动服务 B。而服务 A 发出的请求会被 D-Bus 缓存，服务 A 会等待服务 B 启动就绪。利用这个特性，依赖 D-Bus 的服务就可以实现并行启动。

并发启动原理之三：解决文件系统依赖

系统启动过程中，文件系统相关的活动是最耗时的，比如挂载文件系统，对文件系统进行磁盘检查（fsck），磁盘配额检查等都是非常耗时的操作。在等待这些工作完成的同时，系统处于空闲状态。那些想使用文件系统的服务似乎必须等待文件系统初始化完成才可以启动。但是 systemd 发现这种依赖也是可以避免的。

Systemd 参考了 autofs 的设计思路，使得依赖文件系统的服务和文件系统本身初始化两者可以并发工作。autofs 可以监测到某个文件系统挂载点真正被访问到的时候才触发挂载操作，这是通过内核 automounter 模块的支持而实现的。比如一个 open()系统调用作用在"/misc/cd/file1"的时候，/misc/cd 尚未执行挂载操作，此时 open()调用被挂起等待，Linux 内核通知 autofs，autofs 执行挂载。这时候，控制权返回给 open()系统调用，并正常打开文件。

Systemd 集成了 autofs 的实现，对于系统中的挂载点，比如/home，当系统启动的时候，systemd 为其创建一个临时的自动挂载点。在这个时刻/home 真正的挂载设备尚未启动好，真正的挂载操作还没有执行，文件系统检测也还没有完成。可是那些依赖该目录的进程已经可以并发启动，他们的 open()操作被内建在 systemd 中的 autofs 捕获，将该 open()调用挂起（可中断睡眠状态）。然后等待真正的挂载操作完成，文件系统检测也完成后，systemd 将该自动挂载点替换为真正的挂载点，并让 open()调用返回。由此，实现了那些依赖于文件系统的服务和文件系统本身同时并发启动。

当然对于"/"根目录的依赖实际上一定还是要串行执行，因为 systemd 自己也存放在/之下，必须等待系统根目录挂载检查好。

不过对于类似/home 等挂载点，这种并发可以提高系统的启动速度，尤其是当/home 是远程的 NFS 节点，或者是加密盘等，需要耗费较长的时间才可以准备就绪的情况下，因为并发启动，这段时间内，系统并不是完全无事可做，而是可以利用这段空余时间做更多的启动进程的事情，总的来说就缩短了系统启动时间。

Systemd 的系统管理员使用

systemd 的主要命令行工具是 systemctl。

多数管理员应该都已经非常熟悉系统服务和 init 系统的管理，比如 service、chkconfig 以及 telinit 命令的使用。systemd 也完成同样的管理任务，只是命令工具 systemctl 的语法有所不同而已，因此用表格来对比 systemctl 和传统的系统管理命令会非常清晰。

Systemd 命令和 sysvinit 命令的对照表

Sysvinit 命令	Systemd 命令	备注
service foo start	systemctl start foo.service	用来启动一个服务 (并不会重启现有的)
service foo stop	systemctl stop foo.service	用来停止一个服务 (并不会重启现有的)。
service foo restart	systemctl restart foo.service	用来停止并启动一个服务。
service foo reload	systemctl reload foo.service	当支持时，重新装载配置文件而不中断等待操作。
service foo condrestart	systemctl condrestart foo.service	如果服务正在运行那么重启它。
service foo status	systemctl status foo.service	汇报服务是否正在运行。
ls /etc/rc.d/init.d/	systemctl list-unit-files --type=service	用来列出可以启动或停止的服务列表。
chkconfig foo on	systemctl enable foo.service	在下次启动时或满足其他触发条件时设置服务为启用
chkconfig foo off	systemctl disable foo.service	在下次启动时或满足其他触发条件时设置服务为禁用
chkconfig foo	systemctl is-enabled foo.service	用来检查一个服务在当前环境下被配置为启用还是禁用。
chkconfig –list	systemctl list-unit-files --type=service	输出在各个运行级别下服务的启用和禁用情况
chkconfig foo –list	ls /etc/systemd/system/*.wants/foo.service	用来列出该服务在哪些运行级别下启用和禁用。
chkconfig foo –add	systemctl daemon-reload	当您创建新服务文件或者变更设置时使用。
telinit 3	systemctl isolate multi-user.target (OR systemctl isolate runlevel3.target OR telinit 3)	改变至多用户运行级别。

表中列出的常见用法，系统管理员还需要了解其他一些系统配置和管理任务的改变。

首先我们了解 systemd 如何处理电源管理，命令如下表所示：

命令	操作
systemctl reboot	重启机器
systemctl poweroff	关机
systemctl suspend	待机
systemctl hibernate	休眠
systemctl hybrid-sleep	混合休眠模式（同时休眠到硬盘并待机）

关机不是每个登录用户在任何情况下都可以执行的，一般只有管理员才可以关机。正常情况下系统不应该允许 SSH 远程登录的用户执行关机命令。否则其他用户正在工作，一个用户把系统关了就不好了。为了解决这个问题，传统的 Linux 系统使用 ConsoleKit 跟踪用户登录情况，并决定是否赋予其关机的权限。现在 ConsoleKit 已经被 systemd 的 logind 所替代。

logind 不是 pid-1 的 init 进程。它的作用和 UpStart 的 session init 类似，但功能要丰富很多，它能够管理几乎所有用户会话(session)相关的事情。logind 不仅是 ConsoleKit 的替代，它可以：

• 维护，跟踪会话和用户登录情况。如上所述，为了决定关机命令是否可行，系统需要了解当前用户登录情况，如果用户从 SSH 登录，不允许其执行关机命令；如果普通用户从本地登录，且该用户是系统中的唯一会话，则允许其执行关机命令；这些判断都需要 logind 维护所有的用户会话和登录情况。
• Logind 也负责统计用户会话是否长时间没有操作，可以执行休眠/关机等相应操作。
• 为用户会话的所有进程创建 CGroup。这不仅方便统计所有用户会话的相关进程，也可以实现会话级别的系统资源控制。
• 负责电源管理的组合键处理，比如用户按下电源键，将系统切换至睡眠状态。
• 多席位(multi-seat) 管理。如今的电脑，即便一台笔记本电脑，也完全可以提供多人同时使用的计算能力。多席位就是一台电脑主机管理多个外设，比如两个屏幕和两个鼠标/键盘。席位一使用屏幕 1 和键盘 1；席位二使用屏幕 2 和键盘 2，但他们都共享一台主机。用户会话可以自由在多个席位之间切换。或者当插入新的键盘，屏幕等物理外设时，自动启动 gdm 用户登录界面等。所有这些都是多席位管理的内容。ConsoleKit 始终没有实现这个功能，systemd 的 logind 能够支持多席位。

以上描述的这些管理功能仅仅是 systemd 的部分功能，除此之外，systemd 还负责系统其他的管理配置，比如配置网络，Locale 管理，管理系统内核模块加载等，完整地描述它们已经超出了本人的能力。

systemd 小结

在不才作者看来，作为系统初始化系统，systemd 的最大特点有两个：

• 令人惊奇的激进的并发启动能力，极大地提高了系统启动速度；
• 用 CGroup 统计跟踪子进程，干净可靠。

此外，和其前任不同的地方在于，systemd 已经不仅仅是一个初始化系统了。

systemd加载rc-local.service支持rc.local启动运行脚本

我还可以将脚本放在rcl.local中作为启动加载吗？

如果您正在运行使用Systemd的Linux发行版，那么您可能会发现/etc/rc.local文件中的命令无法在系统启动时运行。

在systemd下rc.local从一个initab脚本变为了rc-local.service

liang@thinkpad:$ systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; enabled-runtime; vendor preset: e
  Drop-In: /usr/lib/systemd/system/rc-local.service.d
           └─debian.conf
   Active: active (exited) since Tue 2019-11-12 14:37:54 CST; 1 day 7h ago
     Docs: man:systemd-rc-local-generator(8)
  Process: 603 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)

我们看到rc.local.service兼容/etc/rc.local

如果：systemctl enable rc-local反馈:

root@Debian-mac:~$ systemctl enable rc-local
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

单元文件没有安装配置（WantedBy，RequiredBy，Alias，[Install]部分中的设置，以及模板单元的DefaultInstance）。
这意味着不打算使用systemctl启用它们。
拥有此类单位的可能原因是：
1）一个单元可以通过与另一个单元的符号链接来静态启用.wants /或.requires /目录。
2）一个单位的目的可能是充当其他具有对它的需求依赖性。
3）可以在需要时通过激活（socket, path, timer,D-Bus, udev，脚本化的systemctl调用...）。
4）如果是模板单元，则应使用一些功能启用该单元指定的实例名称。

默认的service文件都是存在与/etc/systemd/system目录下，有点像某种服务的配置文件。

/lib/systemd/system下也有个rc-local.service，借用这个模板来进行修改，当然你也可以从头开始编写

cp /lib/systemd/system/rc-local.service /etc/systemd/system/rc-local.service

修改内容如下，主要是添加Install细分信息

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

[Install]
WantedBy=multi-user.target

其中Unit大部分主要描述服务的启动顺序以及依赖关系，Service分区主要描述如何启动，Install分区描述如何安装该服务。debian 10已经将/etc/rc.local文件删除了，因此，我们需要手动创建一个，并需要启动执行的命令写入到文件中。

touch /etc/rc.local

不要忘记告诉rc-local.service，/etc/rc.local是可执行的bash脚本。并且可以通过exit 0退出bash

#!/bin/bash
#This script is executed at the end of each multiuser runlevel.Make sure that the script will #“exit 0” on success or any other value on error.
#In order to enable or disable this script just change the execution bits.
#By default this script does nothing.

exit 0

给/etc/rc.local加上补充的权限

chmod a+x /etc/rc.local

然后执行

root@Debian-mac:~# systemctl enable rc.local
Created symlink /etc/systemd/system/multi-user.target.wants/rc-local.service → /etc/systemd/system/rc-local.service.

接着启动这个服务并查看它的状态

systemctl start rc-local.service
systemctl status rc-local.service

命令输出如下

root@Debian-mac:~# systemctl status rc-local.service
● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/rc-local.service.d
           └─debian.conf
   Active: active (exited) since Wed 2019-11-13 23:06:14 CST; 7min ago
  Process: 2250 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)

11月 13 23:06:14 Debian-mac systemd[1]: Starting /etc/rc.local Compatibility...
11月 13 23:06:14 Debian-mac systemd[1]: Started /etc/rc.local Compatibility.

可以rc.local看到中的脚本已经被正确执行了。

下面是rc.local中的注释

This script is executed at the end of each multiuser runlevel.Make sure that the script will “exit 0” on success or any other value on error.
In order to enable or disable this script just change the execution bits.
By default this script does nothing.

echo 1 > /proc/sys/net/ipv4/ip_forward)&

exit 0

从加电到exit 0，我们的debian10已经加载完毕，等待着tty的响应了。

 

参考文献：浅析 Linux 初始化 init 系统 https://www.ibm.com/developerworks/cn/linux/1407_liuming_init1/index.html?ca=drs-