浅析Linux初始化init系统之第3部分: Systemd
2016-03-28 14:43:31 
阿炯
Systemd 的简介和特点
Systemd 是 Linux 系统中最新的初始化系统(init)，它主要的设计目标是克服 sysvinit 固有的缺点，提高系统的启动速度。systemd 和 ubuntu 的 upstart 是竞争对手，预计会取代 UpStart，实际上在作者写作本文时，已经有消息称 Ubuntu 也将采用 systemd 作为其标准的系统初始化系统。
Systemd 的很多概念来源于苹果 Mac OS 操作系统上的 launchd，不过 launchd 专用于苹果系统，因此长期未能获得应有的广泛关注。Systemd 借鉴了很多 launchd 的思想，它的重要特性如下：
同 SysVinit 和 LSB init scripts 兼容
Systemd 是一个"新来的"，Linux 上的很多应用程序并没有来得及为它做相应的改变。和 UpStart 一样，systemd 引入了新的配置方式，对应用程序的开发也有一些新的要求。如果 systemd 想替代目前正在运行的初始化系统，就必须和现有程序兼容。任何一个 Linux 发行版都很难为了采用 systemd 而在短时间内将所有的服务代码都修改一遍。其提供了和 Sysvinit 以及 LSB initscripts 兼容的特性，系统中已经存在的服务和进程无需修改。这降低了系统向 systemd 迁移的成本，使得 systemd 替换现有初始化系统成为可能。
更快的启动速度
Systemd 提供了比 UpStart 更激进的并行启动能力，采用了 Socket/D-Bus activation 等技术启动服务。一个显而易见的结果就是：更快的启动速度。
为了减少系统启动时间，systemd 的目标是：
1.尽可能启动更少的进程
2.尽可能将更多进程并行启动
同样地，UpStart 也试图实现这两个目标。UpStart 采用事件驱动机制，服务可以暂不启动，当需要的时候才通过事件触发其启动，这符合第一个设计目标；此外，不相干的服务可以并行启动，这也实现了第二个目标。
下面的图形演示了 UpStart 相对于 SysVInit 在并发启动这个方面的改进：
图 1. UpStart 对 SysVinit 的改进
假设有 7 个不同的启动项目， 比如 JobA、Job B 等等。在 SysVInit 中，每一个启动项目都由一个独立的脚本负责，它们由 sysVinit 顺序地，串行地调用。因此总的启动时间为 T1+T2+T3+T4+T5+T6+T7。其中一些任务有依赖关系，比如 A,B,C,D。
而 Job E 和 F 却和 A,B,C,D 无关。这种情况下，UpStart 能够并发地运行任务{E,F,(A,B,C,D)}，使得总的启动时间减少为 T1+T2+T3。
这无疑增加了系统启动的并行性，从而提高了系统启动速度。但是在 UpStart 中，有依赖关系的服务还是必须先后启动。比如任务 A,B,(C,D)因为存在依赖关系，所以在这个局部，还是串行执行。
例举一些例子说明， Avahi 服务需要 D-Bus 提供的功能，因此 Avahi 的启动依赖于 D-Bus，UpStart 中，Avahi 必须等到 D-Bus 启动就绪之后才开始启动。类似的，livirtd 和 X11 都需要 HAL 服务先启动，而所有这些服务都需要 syslog 服务记录日志，因此它们都必须等待 syslog 服务先启动起来。然而 httpd 和他们都没有关系，因此 httpd 可以和 Avahi 等服务并发启动。
Systemd 能够更进一步提高并发性，即便对于那些 UpStart 认为存在相互依赖而必须串行的服务，比如 Avahi 和 D-Bus 也可以并发启动。从而实现如下图所示的并发启动过程：
图 2. systemd 的并发启动
所有的任务都同时并发执行，总的启动时间被进一步降低为 T1。
可见 systemd 比 UpStart 更进一步提高了并行启动能力，极大地加速了系统启动时间。
systemd 提供按需启动能力
当 sysvinit 系统初始化的时候，它会将所有可能用到的后台服务进程全部启动运行。并且系统必须等待所有的服务都启动就绪之后，才允许用户登录。这种做法有两个缺点：首先是启动时间过长；其次是系统资源浪费。
某些服务很可能在很长一段时间内，甚至整个服务器运行期间都没有被使用过。比如 CUPS，打印服务在多数服务器上很少被真正使用到。您可能没有想到，在很多服务器上 SSHD 也是很少被真正访问到的。花费在启动这些服务上的时间是不必要的；同样，花费在这些服务上的系统资源也是一种浪费。
Systemd 可以提供按需启动的能力，只有在某个服务被真正请求的时候才启动它。当该服务结束，systemd 可以关闭它，等待下次需要时再次启动它。
Systemd 采用 Linux 的 Cgroup 特性跟踪和管理进程的生命周期
init 系统的一个重要职责就是负责跟踪和管理服务进程的生命周期。它不仅可以启动一个服务，也必须也能够停止服务。这看上去没有什么特别的，然而在真正用代码实现的时候，您或许会发现停止服务比一开始想的要困难。
服务进程一般都会作为精灵进程(daemon)在后台运行，为此服务程序有时候会派生(fork)两次。在 UpStart 中，需要在配置文件中正确地配置 expect 小节。这样 UpStart 通过对 fork 系统调用进行计数，从而获知真正的精灵进程的 PID 号。比如图 3 所示的例子：
图 3. 找到正确 pid
如果 UpStart 找错了，将 p1`作为服务进程的 Pid，那么停止服务的时候，UpStart 会试图杀死 p1`进程，而真正的 p1``进程则继续执行。换句话说该服务就失去控制了。
还有更加特殊的情况。比如，一个 CGI 程序会派生两次，从而脱离了和 Apache 的父子关系。当 Apache 进程被停止后，该 CGI 程序还在继续运行。而我们希望服务停止后，所有由它所启动的相关进程也被停止。
为了处理这类问题，UpStart 通过 strace 来跟踪 fork、exit 等系统调用，但是这种方法很笨拙，且缺乏可扩展性。systemd 则利用了 Linux 内核的特性即 CGroup 来完成跟踪的任务。当停止服务时，通过查询 CGroup，systemd 可以确保找到所有的相关进程，从而干净地停止服务。
CGroup 已经出现了很久，它主要用来实现系统资源配额管理。CGroup 提供了类似文件系统的接口，使用方便。当进程创建子进程时，子进程会继承父进程的 CGroup。因此无论服务如何启动新的子进程，所有的这些相关进程都会属于同一个 CGroup，systemd 只需要简单地遍历指定的 CGroup 即可正确地找到所有的相关进程，将它们一一停止即可。
启动挂载点和自动挂载的管理
传统的 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 命令来查看日志信息。无需自己编写复杂脆弱的字符串分析处理程序。其优点如下：
简单性：代码少，依赖少，抽象开销最小。
零维护：日志是除错和监控系统的核心功能，因此它自己不能再产生问题。举例说，自动管理磁盘空间，避免由于日志的不断产生而将磁盘空间耗尽。
移植性：日志 文件应该在所有类型的 Linux 系统上可用，无论它使用的何种 CPU 或者字节序。
性能：添加和浏览 日志 非常快。
最小资源占用：日志 数据文件需要较小。
统一化：各种不同的日志存储技术应该统一起来，将所有的可记录事件保存在同一个数据存储中。所以日志内容的全局上下文都会被保存并且可供日后查询。例如一条固件记录后通常会跟随一条内核记录，最终还会有一条用户态记录。重要的是当保存到硬盘上时这三者之间的关系不会丢失。Syslog 将不同的信息保存到不同的文件中，分析的时候很难确定哪些条目是相关的。
扩展性：日志的适用范围很广，从嵌入式设备到超级计算机集群都可以满足需求。
安全性：日志 文件是可以验证的，让无法检测的修改不再可能。
Systemd 的基本概念
单元的概念
系统初始化需要做的事情非常多。需要启动后台服务，比如启动 SSHD 服务；需要做配置工作，比如挂载文件系统。这个过程中的每一步都被 systemd 抽象为一个配置单元，即 unit。可以认为一个服务是一个配置单元；一个挂载点是一个配置单元；一个交换分区的配置是一个配置单元；等等。systemd 将配置单元归纳为以下一些不同的类型。然而，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 的对应关系：
表 1. 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 是 desktop-bus 的简称，是一个低延迟、低开销、高可用性的进程间通信机制。它越来越多地用于应用程序之间通信，也用于应用程序和操作系统内核之间的通信。很多现代的服务进程都使用D-Bus 取代套接字作为进程间通信机制，对外提供服务。比如简化 Linux 网络配置的 NetworkManager 服务就使用 D-Bus 和其他的应用程序或者服务进行交互：邮件客户端软件 evolution 可以通过 D-Bus 从 NetworkManager 服务获取网络状态的改变，以便做出相应的处理。
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 的使用。本文只打算给出简单的描述，让您对 systemd 的使用有一个大概的理解。具体的细节内容太多，即无法在一篇短文内写全，本人也没有那么强大的能力。还需要读者自己去进一步查阅 systemd 的文档。
系统软件开发人员
开发人员需要了解 systemd 的更多细节。比如您打算开发一个新的系统服务，就必须了解如何让这个服务能够被 systemd 管理。这需要您注意以下这些要点：
后台服务进程代码不需要执行两次派生来实现后台精灵进程，只需要实现服务本身的主循环即可。
不要调用 setsid()，交给 systemd 处理
不再需要维护 pid 文件。
Systemd 提供了日志功能，服务进程只需要输出到 stderr 即可，无需使用 syslog。
处理信号 SIGTERM，这个信号的唯一正确作用就是停止当前服务，不要做其他的事情。
SIGHUP 信号的作用是重启服务。
需要套接字的服务，不要自己创建套接字，让 systemd 传入套接字。
使用 sd_notify()函数通知 systemd 服务自己的状态改变。一般地，当服务初始化结束，进入服务就绪状态时，可以调用它。
Unit 文件的编写
对于开发者来说，工作量最大的部分应该是编写配置单元文件，定义所需要的单元。
举例来说，开发人员开发了一个新的服务程序，比如 httpd，就需要为其编写一个配置单元文件以便该服务可以被 systemd 管理，类似 UpStart 的工作配置文件。在该文件中定义服务启动的命令行语法，以及和其他服务的依赖关系等。
此外我们之前已经了解到，systemd 的功能繁多，不仅用来管理服务，还可以管理挂载点，定义定时任务等。这些工作都是由编辑相应的配置单元文件完成的。我在这里给出几个配置单元文件的例子。
下面是 SSH 服务的配置单元文件，服务配置单元文件以.service 为文件名后缀。
#cat /etc/system/system/sshd.service
[Unit]
Description=OpenSSH server daemon
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usrsbin/sshd –D $OPTIONS
ExecReload=/bin/kill –HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
文件分为三个小节。第一个是[Unit]部分，这里仅仅有一个描述信息。第二部分是 Service 定义，其中，ExecStartPre 定义启动服务之前应该运行的命令；ExecStart 定义启动服务的具体命令行语法。第三部分是[Install]，WangtedBy 表明这个服务是在多用户模式下所需要的。
那我们就来看下 multi-user.target 吧：
#cat multi-user.target
[Unit]
Description=Multi-User System
Documentation=man.systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescure.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
[Install]
Alias=default.target
第一部分中的 Requires 定义表明 multi-user.target 启动的时候 basic.target 也必须被启动；另外 basic.target 停止的时候，multi-user.target 也必须停止。如果您接着查看 basic.target 文件，会发现它又指定了 sysinit.target 等其他的单元必须随之启动。同样 sysinit.target 也会包含其他的单元。采用这样的层层链接的结构，最终所有需要支持多用户模式的组件服务都会被初始化启动好。
在[Install]小节中有 Alias 定义，即定义本单元的别名，这样在运行 systemctl 的时候就可以使用这个别名来引用本单元。这里的别名是 default.target，比 multi-user.target 要简单一些。。。
此外在/etc/systemd/system 目录下还可以看到诸如*.wants 的目录，放在该目录下的配置单元文件等同于在[Unit]小节中的 wants 关键字，即本单元启动时，还需要启动这些单元。比如您可以简单地把您自己写的 foo.service 文件放入 multi-user.target.wants 目录下，这样每次都会被默认启动了。
最后，让我们来看看 sys-kernel-debug.mout 文件，这个文件定义了一个文件挂载点：
#cat sys-kernel-debug.mount
[Unit]
Description=Debug File Syste
DefaultDependencies=no
ConditionPathExists=/sys/kernel/debug
Before=sysinit.target
[Mount]
What=debugfs
Where=/sys/kernel/debug
Type=debugfs
这个配置单元文件定义了一个挂载点。挂载配置单元文件有一个[Mount]配置小节，里面配置了 What，Where 和 Type 三个数据项。这都是挂载命令所必须的，例子中的配置等同于下面这个挂载命令：
mount –t debugfs /sys/kernel/debug debugfs
配置单元文件的编写需要很多的学习，必须参考 systemd 附带的 man 等文档进行深入学习。希望通过上面几个小例子，大家已经了解配置单元文件的作用和一般写法了。
系统管理员
systemd 的主要命令行工具是 systemctl。
多数管理员应该都已经非常熟悉系统服务和 init 系统的管理，比如 service、chkconfig 以及 telinit 命令的使用。systemd 也完成同样的管理任务，只是命令工具 systemctl 的语法有所不同而已，因此用表格来对比 systemctl 和传统的系统管理命令会非常清晰。
表 2. 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) 改变至多用户运行级别。
除了表 2 列出的常见用法，系统管理员还需要了解其他一些系统配置和管理任务的改变。
首先我们了解 systemd 如何处理电源管理，命令如下表所示：
表 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 已经不仅仅是一个初始化系统了。其替代了 sysvinit 的所有功能，但它并未就此自满。因为 init 进程是系统所有进程的父进程这样的特殊性，systemd 非常适合提供曾经由其他服务提供的功能，比如定时任务 (以前由 crond 完成) ；会话管理 (以前由 ConsoleKit/PolKit 等管理) 。仅仅从本文皮毛一样的介绍来看，Systemd 已经管得很多了，可它还在不断发展。它将逐渐成为一个多功能的系统环境，能够处理非常多的系统管理任务，有人甚至将它看作一个操作系统。
好的一点是，这非常有助于标准化 Linux 的管理！从前，不同的 Linux 发行版各行其事，使用不同方法管理系统，从来也不会互相妥协。比如如何将系统进入休眠状态，不同的系统有不同的解决方案，即便是同一个 Linux 系统，也存在不同的方法，比如一个有趣的讨论：如何让 ubuntu 系统休眠，可以使用底层的/sys/power/state 接口，也可以使用诸如 pm-utility 等高层接口。存在这么多种不同的方法做一件事情对像我这样的普通用户而言可不是件有趣的事情。systemd 提供统一的电源管理命令接口，这件事情的意义就类似全世界的人都说统一的语言，我们再也不需要学习外语了，多么美好！
如果所有的 Linux 发行版都采纳了 systemd，那么系统管理任务便可以很大程度上实现标准化。此外 systemd 有个很棒的承诺：接口保持稳定，不会再轻易改动。对于软件开发人员来说，这是多么让人感动的承诺啊！
1. 初识 Systemd
systemd是Linux系统的一套基本构建模块。它提供了一个系统和服务管理器，作为PID 1运行并启动系统的其余部分。它提供积极的并行化功能，使用套接字和D-Bus激活来启动服务，提供按需启动守护进程，使用Linux控制组跟踪进程，维护挂载和自动挂载点，并实现一个精心设计的基于事务依赖的服务控制逻辑。systemd支持SysV和LSB初始化脚本，可以替代sysvinit。
它是在引导期间启动的第一个守护进程，也是在关闭期间终止的最后一个守护进程。systemd守护进程作为用户空间进程树的根; 第一个进程(PID 1)在Unix系统上具有特殊的作用，因为当原始父进程终止时，它将替换父进程。因此第一个进程特别适合用于监视守护进程。
其他部分包括日志记录守护进程、控制基本系统配置(如主机名、日期、区域设置)的实用程序、维护登录用户和正在运行的容器和虚拟机列表、系统帐户、运行时目录和设置的实用程序，以及管理简单网络配置、网络时间同步、日志转发和名称解析的守护进程。
systemd是目前相当一部分Linux系统上主要的系统守护进程管理工具，其有如下特点：
1.支持并行化任务
2.同时采用socket式与D-Bus总线式激活服务；
3.按需启动守护进程（daemon）；
4.利用Linux的cgroups监视进程；
5.支持快照和系统恢复；
6.维护挂载点和自动挂载点；
7.各服务间基于依赖关系进行精密控制。
核心组件：
systemd
systemctl
systemd-analyze
其他组件：
kernel-install：用于自动将内核及其各自的 initramfs 映像移动到启动分区的脚本
systemd-boot：简单的UEFI引导管理器
systemd-creds：安全地存储和检索 systemd 单元使用的凭据
systemd-cryptenroll：将 PKCS#11、FIDO2、TPM2 令牌/设备注册到 LUKS2 加密卷
systemd-firstboot：首次启动前的基本系统设置初始化
systemd-homed：便携式用户帐户管理
systemd-logind：会话管理
systemd-networkd：网络配置管理
systemd-nspawn：轻量级命名空间容器
systemd-resolved：网络名称解析
systemd-stub：用于创建统一内核映像的 UEFI 引导存根
systemd-sysusers：创建系统用户和组，并在软件包安装或启动时将用户添加到组中
systemd-timesyncd：通过网络同步系统时间
systemd/Timers：用于控制 .service 文件或事件的单调或实时计时器，是 cron 的合理替代方案
systemd-journald：系统日志管理
systemd-localed： 管理系统区域设置
systemd-tmpfiles：是一个负责创建和清理临时文件和目录的实用程序。它通常在启动时运行一次，然后以指定的时间间隔运行。
Systemd可以管理所有系统资源，不同的资源统称为 Unit（单元），Unit一共分成以下12种：
1.Service：装守护进程的启动、停止、重启和重载操作，是最常见的一种 Unit 文件。描述如何管理服务或应用程序。这包括如何启动或停止服务，重新加载其配置文件，服务在什么条件下自动启动，以及相关单元文件的依赖项或层次结构信息。
2.Target：多个Unit构成的一个逻辑组，用于对 Unit 文件进行逻辑分组，引导其它 Unit 的执行。替代了 SysV-init 运行级别的作用，并提供更灵活的基于特定设备事件的启动方式。目标单元用于对单元进行分组并设置同步点以排序与其他单元文件的依赖关系。
3.Device：硬件设备，主要用于定义设备之间的依赖关系。定义已指定由 udev 或 sysfs 文件系统进行 systemd 管理的设备。
4.Mount：文件系统的挂载点，可以替代过去的 /etc/fstab 配置文件。定义系统上由 systemd 管理的挂载点。该文件以挂载路径命名，斜杠改为破折号。 /etc/fstab 中的条目可以自动创建单元。
5.Automount：自动挂载点，相当于 SysV-init 的 autofs 服务。定义自动挂载的挂载点。以它引用的挂载点命名该文件；需要匹配的 .mount 单元文件来定义安装的细节。
6.Path：用于监控指定文件或路径的变化，并触发其它 Unit 运行。定义基于路径的激活的路径。默认情况下，会激活具有相同基本名称的 .service 单元文件。
7.Scope：不是用户创建的，而是 Systemd 运行时产生的，描述一些系统服务的分组信息。该单元文件由 systemd 根据从 D-Bus 接口接收到的信息自动创建，用于管理外部创建的系统进程集。
8.Slice：进程组，用于表示一个 CGroup 的树，通常也不是用户创建的。关联Linux Control Group节点，它允许将资源分配或限制给与切片关联的任何进程。该名称表示控件树中的层次结构。根据单元的类型，单元被默认放置在切片中。
9.Snapshot：Systemd快照，可以切回某个快照。
10. Socket：监控来自于系统或网络的数据消息，用于实现基于数据自动触发服务启动。描述 systemd 用于基于套接字激活的网络、IPC 套接字或 FIFO 缓冲区。当在该单元定义的套接字上看到活动时，会启动一个关联的 .service 文件。
11. Swap：虚拟内存的交换分区。定义系统上的交换空间，单元文件的名称必须反映空间的设备或文件路径。
12. Timer Unit：定时器，用于配置在特定时间触发的任务，替代了 Crontab 的功能。定义由 systemd 管理的计时器。这类似于用于延迟或计划激活的 cron 任务；当计时器到达时，将启动具有相同名称但文件扩展名为 .service 的单元文件。
2. Systemd Service配置文件
每一个被管理单元（Unit）都需要有一个配置文件用于告知systemd对于该单元（Unit）的管理方式。Systemd默认从目录/etc/systemd/system/读取配置文件，但是里面存放的大部分文件都是符号链接，指向目录/lib/systemd/system，配置文件存放于/lib/systemd/system/，开机启动后会在/etc/systemd/system目录建立软链接文件，systemctl enable命令用于在/etc/systemd/system/与/lib/systemd/system/两个目录之间建立符号链接关系。systemctl disable命令用于在两个目录之间撤销符号链接关系，相当于撤销开机启动。配置文件的后缀名，就是该Unit的种类，比如sshd.socket；如果命令行中省略后缀名，Systemd默认后缀名为.service，所以当systemctl enable sshd会被理解成systemctl enable sshd.service。
以sshd.service的配置为例，可用”systemctl cat sshd.service” 命令查看sshd服务的配置文件：
# /lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
Alias=sshd.service
通常一个service服务单元的配置包含3个区块：Unit，Service和Install。
关于 $MAINPID
$MAINPID is a systemd variable for your service that points to the PID of the main application.
$MAINPID是服务的systemd变量，它指向主应用程序的PID。但有些场景下取的不准确或者取到同类其它进程号去了。
2.1 Unit区块
[Unit]区块通常是配置文件的第一个区块，用来定义 Unit 的元数据，以及配置与其他 Unit 的关系。它的主要字段如下：
Description：对该服务的描述
Documentation：文档地址
Requires：本unit需要在哪个服务启动后才能够启动！这里设置服务间的依赖性。如果在此项设置的前导服务没有启动成功，那么本 unit 就不会被启动！
Wants：与Requires 刚好相反，规范的是这个unit之后还会启动什么服务，如果这Wants 后面接的服务如果没有启动成功，不会影响到这个unit本身！
BindsTo：与Requires类似，它指定的 Unit 如果退出，会导致当前Unit停止运行
Before：如果该字段指定的Unit也要启动，那么必须在当前Unit之后启动；与After的意义相反
After：如果该字段指定的Unit也要启动，那么必须在当前Unit之前启动；说明本unit是在哪个服务后启动。仅是说明服务启动的顺序而已，并没有强制要求。
Conflicts：这个项目后面接的服务如果有启动，那么本unit就不能启动！（互斥性） 如果本unit启动了，则指定的服务就不能启动
Condition...：当前Unit运行必须满足的条件，否则不会运行
Assert...：当前Unit运行必须满足的条件，否则会报启动失败
2.2 Service区块
[Service]区块用来Service的配置，只有Service类型的Unit才有这个区块。它的主要字段如下：
Type：定义启动时的进程行为。它有以下几种值。
Type=simple：默认值，执行ExecStart指定的命令，启动主进程
Type=forking：以fork方式从父进程创建子进程，创建后父进程会立即退出
Type=oneshot：一次性进程，Systemd会等当前服务退出，再继续往下执行
Type=dbus：当前服务通过D-Bus启动
Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行
Type=idle：若有其他任务执行完毕，当前服务才会运行
ExecStart：启动当前服务的命令
ExecStartPre：启动当前服务之前执行的命令
ExecStartPost：启动当前服务之后执行的命令
ExecReload：重启当前服务时执行的命令
ExecStop：停止当前服务时执行的命令
ExecStopPost：停止当其服务之后执行的命令
RestartSec：自动重启当前服务间隔的秒数
Restart：定义何种情况Systemd会自动重启当前服务，可能的值包括always（总是重启）、on-success、on-failure、on-abnormal、on-abort、on-watchdog
TimeoutSec：定义Systemd停止当前服务之前等待的秒数
Environment：指定环境变量
KillMode：服务停止类型，默认control-group停止时杀死所有子进程，process只杀主进程，none只停止服务，不杀进程；定义 Systemd 如何停止 sshd 服务。它可以设置的值如下：
- control-group（默认值）：当前控制组里面的所有子进程，都会被杀掉
- process：只杀主进程
- mixed：主进程将收到 SIGTERM 信号，子进程收到 SIGKILL 信号
- none：没有进程会被杀掉，只是执行服务的 stop 命令
Restart：服务重启类型，默认no不重启，on-success正常退出时重启，on-failure非正常退出时重启，Restart扩展：定义了 sshd 退出后，Systemd 的重启方式。它可以设置的值如下：
- no（默认值）：退出后不会重启
- on-success：只有正常退出时（退出状态码为0），才会重启
- on-failure：非正常退出时（退出状态码非0），包括被信号终止和超时，才会重启
- on-abnormal：只有被信号终止和超时，才会重启
- on-abort：只有在收到没有捕捉到的信号终止时，才会重启
- on-watchdog：超时退出，才会重启
- always：不管是什么退出原因，总是重启
注意：对于守护进程，推荐设为on-failure。对于那些允许发生错误退出的服务，可以设为on-abnormal。
RestartSec：间隔多久重启服务。 例如RestartSec=42s
TimeoutSec：若这个服务在启动或者是关闭时，因为某些缘故导致无法顺利 “正常启动或正常结束” 的情况下，则我们要等多久才进入 “强制结束” 的状态！
RemainAfterExit：当设置为 RemainAfterExit=1 时，则当这个服务所属的所有程序都终止之后，此服务会再尝试启动。这对于 Type=oneshot 的服务很有帮助！
EnvironmentFile：通过文件的方式设置环境变量
user：可以设置服务的用户名
2.3 Install区块
[Install]通常是配置文件的最后一个区块，用来定义如何启动，以及是否开机启动。它的主要字段如下:
WantedBy：它的值是一个或多个Target，当前Unit激活时（enable）符号链接会放入/etc/systemd/system目录下面以Target名+.wants后缀构成的子目录中
RequiredBy：它的值是一个或多个Target，当前Unit激活时，符号链接会放入/etc/systemd/system目录下面以Target 名 + .required后缀构成的子目录中
Alias：当前Unit 可用于启动的别名
Also：当前Unit激活（enable）时，会被同时激活的其他Unit
系统的.target的文件信息主要字段含义如下：
Requires：要求basic.target一起运行
Conflicts：冲突字段。如果rescue.service或rescue.target正在运行，multi-user.target就不能运行，反之亦然
After：表示multi-user.target在basic.target 、 rescue.service、 rescue.target之后启动，如果它们有启动的话
AllowIsolate：允许使用systemctl isolate命令切换到multi-user.target
3. 服务监控启动
3.1 socket 触发的服务
涉及网络的服务，可以通过 socket 来触发启动。也就是说服务本身在没连接业务时不用一直空跑着，可以让systemd 帮忙监听一个 socket，以减少资源消耗。当真正有业务连接进来时，才唤醒目标服务。要达成这样的配置，目标服务程序在实现上也有一定要求。
开发一个常规的网络服务，一般有以下几个关键步骤：
1.创建一个 socket
2.调用 bind 将该 socket 绑定一个端口
3.调用 listen 监听端口，将该 socket 变成监听文件描叙符 fd
4.调用 accept 接收一个客户端连接，得到一个新的连接文件描叙符 fd
5.读写连接 socket 的 fd，完成业务逻辑
借助 systemd 强大且通用的服务功能，它可以帮忙完成前两步，并且将 socket 的 fd 传给被激活的程序，后者就只要从第3步开始实现工作。由socker触发的服务对应于 systemd 的配置文件要有两个，后缀分别是.socket与.service ，除后缀外的文件名要相同，这样就能自动关联，例如名为hello-world-socket的服务：
hello-world-socket.socket
[Unit]
Description=Hello World Socket
[Socket]
ListenStream=0.0.0.0:1234
hello-world-socket.service
[Unit]
Description=Hello World Socket Service
[Service]
ExecStart=/absolute/path/to/hello-world-socket.exe
如上，.socket 的配置，需要有 [Socket] 段，ListenStream 字段表示了要监听的地址与端口。相应的 .service 配置，与之前例子一样，描叙了如何启动服务。因为这是想由 socket 激活的 service ，故没有配置重启字段。
在 systemctl 的大多数子命令中，如 start ，其参数默认是假定 .service 单元配置的。例如systemctl start hello-world-socket 等效于 systemctl start hello-world-socket.service 。但在这个例子中，有两种同名单元配置，且按要求先只启动 hello-world-socket.socket ，所以要写完整的单元名：
systemctl start hello-world-socket.socket
3.2 定时器触发的服务
对于定时器触发的服务首先要配置一个 .timer 单元文件，例如：
hello-world.timer
[Unit]
Description=The Hello-World Timer
[Timer]
OnCalendar=*-*-* *:*:00
其中 OnCalendar 的配置格式同 crontab ，上例表示每分钟触发。然后需要一个同名的 .service 单元文件。本文开头编译的 hello-world.exe 正好 可作为该定时器启动的程序，例如：
hello-world.service
[Unit]
Description=The Hello-World Timer
[Service]
Type=oneshot
ExecStart=/absolute/path/to/hello-world.exe
StandardOutput=file:/absolute/path/to/stdout-file
然后启动定时器，并查看状态：
systemctl start hello-world.timer
systemctl status hello-world.timer
4. 服务异常重运行
为了确保服务在遭遇故障时能够自动重启。在Systemd的服务单元文件中，Restart指令是控制服务重启行为的核心设置。这里将探讨Restart=on-failure与Restart=always这两个选项的区别，以帮助开发人员对系统服务做出更适合的选择。Restart指令定义了当服务停止时Systemd的行为。它可以精细控制服务在遇到不同退出情况时是否应该重启。这是确保关键服务可靠性的重要机制，尤其是在生产环境中，服务的持续运行对业务至关重要。
4.1 Restart=on-failure：智能重启
当服务单元文件中设置了Restart=on-failure时，Systemd会在服务因错误退出时尝试重启服务。"错误退出"通常是指服务以非零状态码结束运行，这可能是由于程序崩溃、遇到未处理的异常或其他非正常情况导致的。例如，如果你的服务由于内存不足而崩溃，on-failure将确保服务尝试重新启动。但如果服务是由于正常的系统维护任务而被停止，或者开发人员故意停止服务进行调试，那么它将不会被重启。
其应用场景如下：
生产环境：在不希望因为维护或更新操作而自动重启服务的生产环境中使用。
故障排除：当服务可能需要在出现问题时停止，以便进行故障排除时。
有条件的重启：当你只想在服务因特定问题而停止时重启。
4.2 Restart=always：无条件重启
与on-failure相对的是Restart=always选项。不管服务是如何终止的，系统都会尝试将其重启。这意味着即使服务被管理员有意关闭，或者服务正常结束，Systemd也会立即尝试将其重启。
这种策略适用于那些必须始终运行的服务，无论它们是因为何种原因停止的。这确保了即使在进行系统更新或维护时，服务也能尽可能快地恢复运行。
其应用场景如下：
关键服务：对于那些系统的核心功能，如数据库服务或Web服务器，这些服务的任何停机时间都是不可接受的。
高可用性要求：在需要最大程度减少服务停机时间的环境中。
5. 常用命令使用参考
5.1 systemctl命令的用法
注意：PATTERN、UNIT等其他的变量值后面带...，表示可以传递多个，用空格隔开
UNIT单元不用写后缀，如.service、.target等，systemd会根据子命令的类型自动推断后缀，如下：
systemctl start sshd
与 systemctl start sshd.service 对等
systemctl isolate default
与 systemctl isolate default.target 对等
单元命令
list-units [PATTERN…]：此为默认命令，即 只使用systemctl调用的也是此命令。
列出systemd当前在内存中的单元。这包括直接引用或通过依赖项引用的单元，由应用程序以编程方式固定的单元，或者过去活跃但失败的单元。
默认情况下，只显示活动的、有待处理任务或失败的单元; 可以通过选项--all进行更改。
注意，这个命令不显示单元模板，而只显示单元模板的实例。未实例化的单元模板是不可运行的，因此永远不会出现在该命令的输出中。
具体来说，这意味着foo@.Service永远不会显示在这个列表中——除非实例化，例如foo@bar.service。使用list-unit-files列出已安装的单元模板文件。
pattern要接单元类型后缀，如：systemctl list-units nginx.service
示例：systemctl list-units 列出所有单元
systemctl list-units nginx.service 指定单元
LOAD字段可能的值有：loaded, not-found, bad-setting, error, masked;
ACTIVE字段可能的值有：active, reloading, inactive, failed, activating, deactivating。
is-active [PATTERN…]：检查指定的单元是否是激活状态
示例：systemctl is-active nginx php-fpm
is-failed [PATTERN…]：检查指定的单元是否是失败状态
示例：systemctl is-failed nginx php-fpm
status [PATTERN…|PID…]]：显示单元的运行时状态信息，如果不接单元名或进程id，则显示整个系统单元的状态信息，整个系统单元的状态会以树状结构来显示输出。
示例：
systemctl status
systemctl status nginx php-fpm
systemctl status 924，924是PID，此时对应的是php-fpm进程
status命令输出人类可读的格式文本，如果想要输出计算机可解析的格式，则使用show命令代替。status命令只显示正在运行，或最近运行过并尚未从内存中释放的单元的信息，要获取早期运行过的单元日志信息，使用journalctl命令获取。
Loaded：配置文件的位置，是否设为开机启动，disabled代表启用
Active：active (running) 表示正在运行
Main PID：主进程ID
CGroup：应用的所有子进程，三个nginx进程
日志块：应用的日志
注意：status命令会隐式加载单元，如果以此返回的状态信息来判断单元是否已经被加载有时是不准确的，因为隐式加载后可能随后就会快速取消加载。
图标的颜色和形状表示的状态：
“未激活”或“维护”是一个白色圆圈(“〇”)，“激活”是一个绿色圆点(“●”)，“停用”是一个白点，“失败”或“错误”是一个红色的十字(“x”)，“重新加载”是一个绿色的顺时针圆形箭头("↻")。
show [PATTERN…|JOB…]：
显示一个或多个单元、任务或systemd本身的属性。如果没有指定参数，将显示systemd的属性。如果指定了单元名称，则显示单元的属性; 如果指定了任务ID，则显示任务的属性。默认情况下，空属性将被抑制。使用--all来显示这些。要选择要显示的特定属性，使用--property=来指定。该命令用于任何需要计算机可解析输出的情况。
示例：
systemctl show
systemctl show nginx
cat PATTERN…：显示单元的配置文件内容，每个文件前面都有一个包含文件名的注释，如果磁盘上的任何单元文件被更新，并且没有发出daemon-reload命令，此时显示的配置文件内容不是最新的。
示例：systemctl cat nginx php-fpm
help PATTERN…|PID…：显示指定单元的手册页，也可传PID，当然如果在配置中没有定义手册这一项，则不会输出。
示例：systemctl help nginx
list-dependencies [UNIT...]：显示指定单位所需和想要的依赖单位。这将递归列出遵循 Requires=、Requisite=、Wants=、ConsistsOf=、BindsTo= 和 Upholds= 依赖项的单元。如果未指定单位，则默认是default.target。默认情况下，仅递归扩展目标单元。当--all 被传递时，所有其他单元也会递归扩展。
示例：
systemctl list-dependencies
systemctl list-dependencies nginx
start PATTERN…：启动单元，或者叫激活指定的单元，可以传--all启动所有单元
示例：
systemctl start nginx php-fpm
systemctl start --all
stop PATTERN…：停止单元，或者叫停用指定的单元
如果单元不存在或已经停止则会操作失败；如果单元配置了ExecStop=选项，则stop命令不会失败，因为systemd将会强制终止单元。
示例：systemctl stop nginx php-fpm
reload PATTERN…：重新加载单元里面指定的服务进程配置文件，例如：nginx、php-fpm的自身的配置文件，不是systemd的单元配置文件。
示例：systemctl reload nginx php-fpm
restart PATTERN…：重启指定的单元，内部逻辑为：先停止后启动，如果单元没有在运行，则只会启动。注意此命令是平滑重启，单元储存的资源会保留，只要单元有一个待办的任务，并且只有在单元完全停止并且不再有任务待办时才会被清除。
示例：systemctl restart nginx php-fpm
try-restart PATTERN…：停止然后启动指定的单元且仅仅在单元是运行状态时，如果单元不在运行，则不做任何操作。
示例：systemctl try-restart nginx php-fpm
reload-or-restart PATTERN…：如果单元支持重载配置，即配置了ExecReload选项时，则执行重载操作，否则执行重启操作；如果单元没有在运行，则执行启动操作。
示例：systemctl reload-or-restart nginx php-fpm
try-reload-or-restart PATTERN…：与reload-or-restart相似，不同的是当单元没有在运行，则不执行任何操作。
示例：systemctl try-reload-or-restart nginx php-fpm
isolate [UNIT]：启动指定的单元及其依赖项并停止所有其他单元，除非它们具有 IgnoreOnIsolate=yes选项。如果给出的单元名称没有扩展名，则将假定扩展名为“.target”。
此命令很危险，因为它会立即停止新目标中未启用的进程，可能包括当前正在使用的图形环境或终端。此命令仅在启用了AllowIsolate的设备上才允许执行此操作。
示例：systemctl isolate nginx
freeze PATTERN…：冻结指定的单元
冻结该单元将导致cgroup中与该单元对应的所有进程被挂起。被挂起意味着单元的进程在解冻之前不会被安排在CPU上运行。注意该命令仅支持使用统一cgroup层次结构的系统。单元在我们对单元执行作业之前自动解冻，例如，在单元停止之前。
示例：systemctl freeze nginx php-fpm
thaw PATTERN…：解冻指定的单元
这是 freeze 命令的逆操作，恢复单元 cgroup 中进程的执行。
示例：systemctl thaw nginx php-fpm
set-property UNIT PROPERTY=VALUE…：
在运行时设置支持的指定单元属性。这允许在运行时更改配置参数属性，例如资源控制设置。并非所有属性都可以在运行时更改，但是许多资源控制设置可以。这些更改将立即应用，并存储在磁盘上以备以后的引导，
除非传递了--runtime参数，在这种情况下，这些设置只应用到下一次重新引导。如果指定的单元处于非活动状态，则更改将仅存储在磁盘上，因此它们将在单元启动时生效。
示例：systemctl set-property foobar.service CPUWeight=200
可以一次性设置多个属性
示例：systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes
与单元文件配置设置一样，分配空设置通常会将属性重置为其默认值
示例：systemctl set-property avahi-daemon.service IPAddressDeny=
单元文件相关的命令
list-unit-files [PATTERN…]：列出系统上安装的单元文件，连同它们的启用状态，与 list-units 不同，此命令除了显式实例化的单元外还将列出模板单元。
enable UNIT…, enable PATH…：
启用一个或多个单元或单元实例。
将创建一组符号链接，在创建了符号链接之后，系统管理器配置将被重新加载(在某种程度上相当于daemon-reload)，这并不会同时启动任何已启用的单元，只是systemd读取到了此单元，可以在systemd开机自启时自动启动，如果需要启用后立马启动，则可以接--now，内部调用start命令启动。
示例：systemctl enable nginx php-fpm
disable UNIT…：
禁用一个或多个单位，使得不能在开机时自动启动。这将从单元配置目录中删除到支持指定单元的单元文件的所有符号链接，并因此撤消由enable或link所做的任何更改。
除了指定的单元外，此单元文件的 [Install] 部分中包含的 Also= 设置中列出的所有单元均被禁用。该命令在完成操作后隐式地重新加载系统管理器配置，即执行daemon-reload。注意该命令不会隐式停止正在禁用的单元。如果需要这样做，可以将该命令与--now开关结合使用，内部调用了stop命令。
示例：systemctl disable nginx php-fpm
reenable UNIT…：
重新启用一个或多个单元。这是disable和enable的组合，用于将单元文件启用的符号链接重置为[Install]节中配置的默认值。这个命令只需要单元名，它不接受单元文件的路径。
示例：systemctl reenable nginx php-fpm
is-enabled UNIT…：检查指定的单元是否是启用状态
示例：systemctl is-enabled nginx php-fpm
mask UNIT…：
屏蔽指定的单元。这将把这些单元文件链接到/dev/null，使它们无法启动。这是一个更强的disable版本，因为它禁止所有类型的单元激活，包括启用和手动激活。
请谨慎使用此选项。这允许--runtime选项暂时屏蔽，直到下次重新启动系统。--now选项可用于确保单元也被停止。这个命令只需要有效的单元名，它不接受单元文件路径。
示例：systemctl mask nginx php-fpm
unmask UNIT…：取消屏蔽指定的单元。
示例：systemctl unmask nginx php-fpm
revert UNIT…：撤销或者叫还原指定单元的配置到厂商原配置
将指定单元文件还原到它们的供应商版本。该命令删除修改指定单元的插入式配置文件，以及覆盖匹配供应商提供的单元文件的任何用户配置的单元文件。
具体来说，对于一个单元“foo.service“匹配的目录”foo.service.d/"及其包含的所有文件被删除，包括持久配置目录和运行时配置目录(即/etc/systemd/system和/run/systemd/system)下的文件;
同样，如果一个单元被屏蔽，它将被解除屏蔽。实际上此命令可用于撤消使用 systemctl edit、systemctl set-property 和 systemctl mask 所做的所有更改，并使原始单元文件及其设置重新生效。
示例：systemctl revert nginx php-fpm
edit UNIT…：编辑单元文件，用来扩展或覆写原来的单元文件
根据是否指定了--system(默认值)、--user或--global，该命令将为系统、调用用户或所有用户的所有未来登录的每个单元创建一个插入文件。然后，在临时文件上调用编辑器，如果编辑器成功退出，这些临时文件将被写入实际位置。
如果指定了--drop-in=[filename]，则将使用给定的 drop-in 文件名而不是默认的 override.conf。
如果指定了--full，将复制原始单元文件而不是创建嵌入式文件。
如果指定了--force，并且任何单位尚不存在，则将打开新的单位文件进行编辑。
如果指定了--runtime，则更改将暂时在 /run/ 中进行，并且它们将在下次重新启动时丢失。
如果退出时临时文件为空，则取消相关单元的修改。编辑单元后，将重新加载 systemd 配置（以相当于调用了daemon-reload）。
示例：systemctl edit nginx php-fpm
get-default：获取默认target的单元名称，实际上是default.target的符号链接。
示例：systemctl get-default
set-default TARGET：设置默认的target，实际上是将default.target的符号链接设置为指定的目标单元
示例：systemctl set-default multi-user.target
机器命令
list-machines [PATTERN…]：列出主机和所有正在运行的本地容器及其状态。
示例：systemctl list-machines
任务命令
list-jobs [PATTERN…]：列出正在进行的任务
示例：systemctl list-jobs
cancel [JOBID…]：取消指定的任务，通过任务id来指定，如果没有指定任务id，则取消所有待处理的任务。
示例：systemctl cancel 1608941
管理器状态命令
daemon-reload：
重新加载systemd管理器配置，重新加载所有单元文件，并重新创建整个依赖树。
示例：systemctl daemon-reload
系统命令
is-system-running：检查systemd系统是否正在运行
示例：systemctl is-system-running
输出的值有如下几种：
initializing：正在初始化
starting：正在启动
running：正在运行
degraded：系统正在运行，但一个或多个单元出现故障。
maintenance：系统处于维护模式
stopping：系统正在停止
offline：系统已经离线
unknown：未知错误，由于缺乏资源或其他错误原因，无法确定操作状态。
default：进入默认模式，相当于调用了 systemctl isolate default.target
示例：systemctl default
rescue：进入拯救模式，相当于调用了 systemctl isolate rescue.target
示例：systemctl rescue
emergency：进入紧急模式，相当于调用了 systemctl isolate emergency.target
示例：systemctl emergency
halt：关闭并停止系统，但硬件还是处于开机状态，相当于调用了 systemctl start halt.target。
如果接 --force，则强制停止系统，所有进程将被杀死。如果接 --when=，when指定时间戳，则在指定的时间戳之后停止系统，如果--when=cancel，则取消关闭系统的操作。
示例：systemctl halt
poweroff：停止系统并关机，硬件处于关机状态，相当于调用了 systemctl start poweroff.target。也可接 --force和--when，行为与上述相似
示例：systemctl poweroff
reboot：关闭并重新启动系统，相当于调用了 systemctl start reboot.target。也可以接 --force和--when，行为与上述相似
示例：systemctl reboot
suspend：暂停或者叫挂起系统，内部会触发调用 suspend.target
示例：systemctl suspend
hibernate：使系统休眠，内部会触发调用 hibernate.target
示例：systemctl hibernate
hybrid-sleep：休眠并挂起系统，内部会触发调用 hybrid-sleep.target
示例：systemctl hybrid-sleep
常用的选项
-t, --type=：显示指定类型的单元，多个类型用逗号隔开；例如指定为service、socket，多用于 list-units, list-dependencies, show, status 子命令。注意如果指定 -t help，则打印出所有可用的类型值
示例：systemctl status -t service
--state=：显示指定状态的单元，多个状态用逗号隔开；例如指定为failed、active，多用于 list-units, list-dependencies, show, status
示例：systemctl status --state=failed
-p, --property=：显示指定的unit/job/manager的属性，多个属性名用逗号隔开；例如：MainPID
示例：systemctl show -p LogLevel
-a, --all：
用途场景如下：
当使用 list-units 列出单位时，还显示非活动单位和跟随其他单位的单位。
当显示单位/任务/manager属性时，显示所有属性，无论是否设置。
当显示单位的依赖时：list-dependencies，递归地显示所有依赖单元的依赖关系。
当与status一起使用时，显示完整的日志消息，即使它们包含不可打印的字符。
示例：
systemctl list-units -a
--with-dependencies：
当与 status、cat、list-units 和 list-unit-files 一起使用时，这些命令会打印所有指定的单元以及这些单元的依赖关系。
示例：
systemctl status --with-dependencies
-q, --quiet：
禁止打印各种命令的结果以及关于截断的日志行的提示。但错误总是打印出来。
示例：systemctl start nginx -q
--no-warn：抑制警告信息
示例：systemctl start nginx --no-warn
--no-block：不同步等待请求的操作完成。
使systemd耗时的操作变为异步，此选项与 --wait 选项互斥。
示例：systemctl default --no-block
--wait：同步等待请求的操作完成。与 --no-block 互斥。
示例：systemctl default --wait
-f, --force：强制操作
使用场景如下：
使用 enable 时，覆盖掉任何已存在冲突的符号链接
使用 edit 时，如果指定的单元不存在，则自动创建
在使用 halt, poweroff, reboot时，会强制关闭系统，强制杀死进程。
-o, --output=：控制在使用 status 时的输出格式，详情参考下方 journal的说明。
示例：systemctl status -o short-iso
--plain：当在使用 list-dependencies, list-units, list-machines 时，输出为列表的形式而不是树形结构。
示例：systemctl list-units --plain
-h, --help：打印帮助信息
示例：systemctl -h
--version：打印版本号
systemctl --version
5.2 journalctl常用选项的用法
如果不带参数调用，它将显示调用用户可访问的日志内容，从最早的历史日志开始显示，所以内容多的话会很卡，一般无参调用。
--system, --user：显示来自系统服务和内核的消息（使用 --system）。显示来自当前用户服务的消息（使用 --user）。如果两者均未指定，则显示用户可以看到的所有消息。
示例：journalctl --user
-u, --unit=UNIT|PATTERN：指定服务单元名称，或单元匹配模式，此选项可使用多次。
示例：journalctl -u nginx
-p, --priority=：通过优先级过滤日志信息，可指定单个日志级别或范围级别。
日志有8个级别，可用数字表示，也可用文本表示，如下：
emerg(Emergency): 0, // 紧急，表示系统无法使用，需要立即处理。
alert(Alert): 1, // 警报，表示需要立即采取行动来解决关键问题。
crit(Critical): 2, // 严重，表示程序中需要干预以防止系统故障的关键条件。
err(Error): 3, // 错误，表示影响某些操作但不如紧急情况严重的错误情况。
warning(Warning): 4, // 警告，表示如果不解决，将来可能会导致错误或意外行为的潜在问题。
notice(Notice): 5, // 注意，适用于可能需要监测的正常但重要的情况。
info(Informational): 6, // 信息，包括提供系统正常运行记录的消息。
debug(Debug): 7 // debug信息，用于记录有关系统的详细信息以进行调试。
如果指定的是单个级别，则会显示小于等于指定级别的日志信息，例如：指定的是4，则显示 <=4 的日志信息；如果指定的是级别范围，格式为：FROM..TO，之间是两个点，则会显示包括开始和结束边界值的日志信息，例如：指定 1..4，则显示1、2、3、4的日志信息。
示例：
journalctl -p 4
journalctl -p 1..4
-g, --grep：使用正则表达式匹配过滤
如果模式字符串全小写，则匹配是不区分大小写的，否则是区分的，也可以接--case-sensitive覆盖此行为。
示例：journalctl -g ^ng
--case-sensitive[=BOOLEAN]：接上，指定匹配是否区分大小写，值为：true或false。
示例：journalctl -g ^nG --case-sensitive=true
-k, --dmesg：仅仅显示内核日志信息，此选项相当于隐式使用了 -b，和添加了 _TRANSPORT=kernel。
示例：journalctl -k
-o, --output=：控制日志的输出格式，有如下多个格式可选：
short：此为默认格式，生成的输出与经典系统日志文件的格式基本相同，每个日志条目显示一行。
short-full：与short显示的时间戳信息不同，此模式在输出中包含工作日、年份和时区信息，并且与语言环境无关。
short-iso：时间戳显示的ISO 8601的时间格式，如：2024-04-30T01:23:38+0800。
short-iso-precise：与short-iso相似，但包含完整的微秒部分。
short-precise：与short相似，但包含完整的微秒部分。
short-unix：与short相似，但显示的是unix时间戳，自 UTC 1970年1月1日以来经过的秒数，并包含微秒部分。
verbose：显示完整结构的日志信息。
json：显示成json格式，一条记录一行。
如果字段超过4096个字节，将会编码为null值，但可接 --all来取消这个默认行为。
日志条目允许同一日志条目中存在非唯一字段。 JSON 不允许对象内存在非唯一字段。因此，如果遇到非唯一字段，则会使用 JSON 数组作为字段值，将所有字段值列出为元素。包含不可打印或非 UTF8 字节的字段被编码为包含单独格式化为无符号数字的原始字节的数组。
json-pretty：美化输出json格式，每个字段占一行。
cat：生成一个简洁的输出，仅仅显示日志本身的信息，不附带元数据和时间戳。
with-unit：与short-full类似，但前缀为单元和用户单元名称，而不是传统的syslog标识符。使用模板化实例时很有用，因为它将在单元名称中包含参数。
--output-fields=：指定日志信息输出的字段，多个用逗号隔开，只对显示所有字段的输出模式有效，包括：verbose, export, json, json-pretty, json-sse, json-seq, cat。
可用的字段参考json格式输出的字段。
示例：journalctl -u nginx -o json-pretty --output-fields=PRIORITY,__CURSOR
-r, --reverse：反转输出，最新的日志展示在上面。
-a, --all：完整显示所有字段，即使它们包含不可打印的字符或非常长。默认情况下，具有不可打印字符的字段缩写为“blob data”。
-f, --follow：仅仅显示最新的日志，只要有新日志追加进来则一直打印输出，与tail -f 相似。
-q, --quiet：禁止所有信息性消息（即“-- Journal begins at”、“-- Reboot --”）以及以普通用户身份运行时有关无法访问的系统日志的任何警告消息。
--disk-usage：显示所有日志文件的当前磁盘使用情况。这显示了所有已归档和活动日志文件的磁盘使用量总和。
-h, --help：打印帮助信息
--version：打印版本号
5.3 其他组件的用法
hostnamectl
可用于打印主机名、图标名、设备类型、机器ID、操作系统类型、内核及其架构类型等等。
systemd-analyze
使用systemd-analyze命令可以分析系统启动过程的性能。该命令还可用于从系统和服务管理器检索其他状态和跟踪信息。它用于检查单元文件是否正确，也用于访问高级系统管理器调试有用的特殊功能。
例如：查看系统启动所需的时间
systemd-analyze time
Startup finished in 3.404s (kernel) + 2.415s (initrd) + 13.125s (userspace) = 18.945s
graphical.target reached after 13.117s in userspace
获得服务启动过程的高级概述，其中包括启动的服务和每个服务启动所需的时间
systemd-analyze critical-chain
该命令为每个指定的单元或默认目标打印时间关键单元树。查看服务启动过程中启动的服务列表，并显示每个服务所花费的时间。
systemd-analyze blame
可用使用systemd-analyze生成一个矢量图形文件，显示启动过程中发生的事件
systemd-analyze plot > /temp/sample.svg
LibreOffice Draw 等应用程序可以使用这些向量来生成图形。
使用 systemd-analyze verify 检查 systemd 单元文件的语法
systemd-analyze verify /etc/systemd/system/my-custom-service.service
该命令分析单元文件并报告任何语法错误、丢失文件或其他问题。
6、简单判断当前的Linux操作系统是否使用了systemd来作为初始系统
1.检查进程号为1的进程
毕竟，init系统是Linux操作系统上运行的第一个进程。
ps 1
通过输出结果会发现通常会指向/sbin/init，通过该（符号链接或文件）就可以获得init系统信息，可以使用指令：
1).stat
2).readlink
# stat /sbin/init
输出一：使用了sysvinit的init的情况
文件：/sbin/init
大小：52240 块：104 IO 块：4096 普通文件
设备：801h/2049d Inode：50332049 硬链接：1
权限：(0755/-rwxr-xr-x) Uid：( 0/ root) Gid：( 0/ root)
最近访问：2024-12-08 21:30:33.723266301 +0800
最近更改：2021-04-24 17:41:23.000000000 +0800
最近改动：2021-10-24 21:00:10.916002352 +0800
创建时间：2021-10-24 21:00:10.900002351 +0800
输出二：使用了systemd的init系统的情况
文件：/sbin/init -> /lib/systemd/systemd
大小：20 块：0 IO 块：4096 符号链接
设备：803h/2051d Inode：805307368 硬链接：1
权限：(0777/lrwxrwxrwx) Uid：( 0/ root) Gid：( 0/ root)
最近访问：2024-10-15 18:53:31.483460146 +0800
最近更改：2022-08-07 21:25:09.000000000 +0800
最近改动：2022-11-21 01:15:30.617588015 +0800
创建时间：2022-11-21 01:15:30.477588011 +0800
如果是链接，可通过'readlink /sbin/init'来查看实际文件的位置。
如果系真实文件而非链接文件，可用'readlink -f /sbin/init'查看到实际文件的路径信息。
结束语
本系列文章从古老却简明稳定的 sysvinit 说起，接着简要描述了 UpStart 带来的清新改变，最后看到了充满野心和活力的新生代 systemd 系统逐渐统治 Linux 的各个版本。就好像在看我们这个世界，一代人老去，新的一代带着横扫一切的气概登上舞台，还没有喊出他们最有力的口号，更猛的一代已经把聚光灯和所有的目光带走。Systemd 之后也许还有更新的 init 系统出现吧，让我们继续期待。。。
本文源自IBM DeveloperWorks 中文社区，作者：刘明
Systemd 是 Linux 系统中最新的初始化系统(init)，它主要的设计目标是克服 sysvinit 固有的缺点，提高系统的启动速度。systemd 和 ubuntu 的 upstart 是竞争对手，预计会取代 UpStart，实际上在作者写作本文时，已经有消息称 Ubuntu 也将采用 systemd 作为其标准的系统初始化系统。
Systemd 的很多概念来源于苹果 Mac OS 操作系统上的 launchd，不过 launchd 专用于苹果系统，因此长期未能获得应有的广泛关注。Systemd 借鉴了很多 launchd 的思想，它的重要特性如下：
同 SysVinit 和 LSB init scripts 兼容
Systemd 是一个"新来的"，Linux 上的很多应用程序并没有来得及为它做相应的改变。和 UpStart 一样，systemd 引入了新的配置方式，对应用程序的开发也有一些新的要求。如果 systemd 想替代目前正在运行的初始化系统，就必须和现有程序兼容。任何一个 Linux 发行版都很难为了采用 systemd 而在短时间内将所有的服务代码都修改一遍。其提供了和 Sysvinit 以及 LSB initscripts 兼容的特性，系统中已经存在的服务和进程无需修改。这降低了系统向 systemd 迁移的成本，使得 systemd 替换现有初始化系统成为可能。
更快的启动速度
Systemd 提供了比 UpStart 更激进的并行启动能力，采用了 Socket/D-Bus activation 等技术启动服务。一个显而易见的结果就是：更快的启动速度。
为了减少系统启动时间，systemd 的目标是：
1.尽可能启动更少的进程
2.尽可能将更多进程并行启动
同样地，UpStart 也试图实现这两个目标。UpStart 采用事件驱动机制，服务可以暂不启动，当需要的时候才通过事件触发其启动，这符合第一个设计目标；此外，不相干的服务可以并行启动，这也实现了第二个目标。
下面的图形演示了 UpStart 相对于 SysVInit 在并发启动这个方面的改进：
图 1. UpStart 对 SysVinit 的改进
假设有 7 个不同的启动项目， 比如 JobA、Job B 等等。在 SysVInit 中，每一个启动项目都由一个独立的脚本负责，它们由 sysVinit 顺序地，串行地调用。因此总的启动时间为 T1+T2+T3+T4+T5+T6+T7。其中一些任务有依赖关系，比如 A,B,C,D。
而 Job E 和 F 却和 A,B,C,D 无关。这种情况下，UpStart 能够并发地运行任务{E,F,(A,B,C,D)}，使得总的启动时间减少为 T1+T2+T3。
这无疑增加了系统启动的并行性，从而提高了系统启动速度。但是在 UpStart 中，有依赖关系的服务还是必须先后启动。比如任务 A,B,(C,D)因为存在依赖关系，所以在这个局部，还是串行执行。
例举一些例子说明， Avahi 服务需要 D-Bus 提供的功能，因此 Avahi 的启动依赖于 D-Bus，UpStart 中，Avahi 必须等到 D-Bus 启动就绪之后才开始启动。类似的，livirtd 和 X11 都需要 HAL 服务先启动，而所有这些服务都需要 syslog 服务记录日志，因此它们都必须等待 syslog 服务先启动起来。然而 httpd 和他们都没有关系，因此 httpd 可以和 Avahi 等服务并发启动。
Systemd 能够更进一步提高并发性，即便对于那些 UpStart 认为存在相互依赖而必须串行的服务，比如 Avahi 和 D-Bus 也可以并发启动。从而实现如下图所示的并发启动过程：
图 2. systemd 的并发启动
所有的任务都同时并发执行，总的启动时间被进一步降低为 T1。
可见 systemd 比 UpStart 更进一步提高了并行启动能力，极大地加速了系统启动时间。
systemd 提供按需启动能力
当 sysvinit 系统初始化的时候，它会将所有可能用到的后台服务进程全部启动运行。并且系统必须等待所有的服务都启动就绪之后，才允许用户登录。这种做法有两个缺点：首先是启动时间过长；其次是系统资源浪费。
某些服务很可能在很长一段时间内，甚至整个服务器运行期间都没有被使用过。比如 CUPS，打印服务在多数服务器上很少被真正使用到。您可能没有想到，在很多服务器上 SSHD 也是很少被真正访问到的。花费在启动这些服务上的时间是不必要的；同样，花费在这些服务上的系统资源也是一种浪费。
Systemd 可以提供按需启动的能力，只有在某个服务被真正请求的时候才启动它。当该服务结束，systemd 可以关闭它，等待下次需要时再次启动它。
Systemd 采用 Linux 的 Cgroup 特性跟踪和管理进程的生命周期
init 系统的一个重要职责就是负责跟踪和管理服务进程的生命周期。它不仅可以启动一个服务，也必须也能够停止服务。这看上去没有什么特别的，然而在真正用代码实现的时候，您或许会发现停止服务比一开始想的要困难。
服务进程一般都会作为精灵进程(daemon)在后台运行，为此服务程序有时候会派生(fork)两次。在 UpStart 中，需要在配置文件中正确地配置 expect 小节。这样 UpStart 通过对 fork 系统调用进行计数，从而获知真正的精灵进程的 PID 号。比如图 3 所示的例子：
图 3. 找到正确 pid
如果 UpStart 找错了，将 p1`作为服务进程的 Pid，那么停止服务的时候，UpStart 会试图杀死 p1`进程，而真正的 p1``进程则继续执行。换句话说该服务就失去控制了。
还有更加特殊的情况。比如，一个 CGI 程序会派生两次，从而脱离了和 Apache 的父子关系。当 Apache 进程被停止后，该 CGI 程序还在继续运行。而我们希望服务停止后，所有由它所启动的相关进程也被停止。
为了处理这类问题，UpStart 通过 strace 来跟踪 fork、exit 等系统调用，但是这种方法很笨拙，且缺乏可扩展性。systemd 则利用了 Linux 内核的特性即 CGroup 来完成跟踪的任务。当停止服务时，通过查询 CGroup，systemd 可以确保找到所有的相关进程，从而干净地停止服务。
CGroup 已经出现了很久，它主要用来实现系统资源配额管理。CGroup 提供了类似文件系统的接口，使用方便。当进程创建子进程时，子进程会继承父进程的 CGroup。因此无论服务如何启动新的子进程，所有的这些相关进程都会属于同一个 CGroup，systemd 只需要简单地遍历指定的 CGroup 即可正确地找到所有的相关进程，将它们一一停止即可。
启动挂载点和自动挂载的管理
传统的 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 命令来查看日志信息。无需自己编写复杂脆弱的字符串分析处理程序。其优点如下：
简单性：代码少，依赖少，抽象开销最小。
零维护：日志是除错和监控系统的核心功能，因此它自己不能再产生问题。举例说，自动管理磁盘空间，避免由于日志的不断产生而将磁盘空间耗尽。
移植性：日志 文件应该在所有类型的 Linux 系统上可用，无论它使用的何种 CPU 或者字节序。
性能：添加和浏览 日志 非常快。
最小资源占用：日志 数据文件需要较小。
统一化：各种不同的日志存储技术应该统一起来，将所有的可记录事件保存在同一个数据存储中。所以日志内容的全局上下文都会被保存并且可供日后查询。例如一条固件记录后通常会跟随一条内核记录，最终还会有一条用户态记录。重要的是当保存到硬盘上时这三者之间的关系不会丢失。Syslog 将不同的信息保存到不同的文件中，分析的时候很难确定哪些条目是相关的。
扩展性：日志的适用范围很广，从嵌入式设备到超级计算机集群都可以满足需求。
安全性：日志 文件是可以验证的，让无法检测的修改不再可能。
Systemd 的基本概念
单元的概念
系统初始化需要做的事情非常多。需要启动后台服务，比如启动 SSHD 服务；需要做配置工作，比如挂载文件系统。这个过程中的每一步都被 systemd 抽象为一个配置单元，即 unit。可以认为一个服务是一个配置单元；一个挂载点是一个配置单元；一个交换分区的配置是一个配置单元；等等。systemd 将配置单元归纳为以下一些不同的类型。然而，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 的对应关系：
表 1. 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 是 desktop-bus 的简称，是一个低延迟、低开销、高可用性的进程间通信机制。它越来越多地用于应用程序之间通信，也用于应用程序和操作系统内核之间的通信。很多现代的服务进程都使用D-Bus 取代套接字作为进程间通信机制，对外提供服务。比如简化 Linux 网络配置的 NetworkManager 服务就使用 D-Bus 和其他的应用程序或者服务进行交互：邮件客户端软件 evolution 可以通过 D-Bus 从 NetworkManager 服务获取网络状态的改变，以便做出相应的处理。
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 的使用。本文只打算给出简单的描述，让您对 systemd 的使用有一个大概的理解。具体的细节内容太多，即无法在一篇短文内写全，本人也没有那么强大的能力。还需要读者自己去进一步查阅 systemd 的文档。
系统软件开发人员
开发人员需要了解 systemd 的更多细节。比如您打算开发一个新的系统服务，就必须了解如何让这个服务能够被 systemd 管理。这需要您注意以下这些要点：
后台服务进程代码不需要执行两次派生来实现后台精灵进程，只需要实现服务本身的主循环即可。
不要调用 setsid()，交给 systemd 处理
不再需要维护 pid 文件。
Systemd 提供了日志功能，服务进程只需要输出到 stderr 即可，无需使用 syslog。
处理信号 SIGTERM，这个信号的唯一正确作用就是停止当前服务，不要做其他的事情。
SIGHUP 信号的作用是重启服务。
需要套接字的服务，不要自己创建套接字，让 systemd 传入套接字。
使用 sd_notify()函数通知 systemd 服务自己的状态改变。一般地，当服务初始化结束，进入服务就绪状态时，可以调用它。
Unit 文件的编写
对于开发者来说，工作量最大的部分应该是编写配置单元文件，定义所需要的单元。
举例来说，开发人员开发了一个新的服务程序，比如 httpd，就需要为其编写一个配置单元文件以便该服务可以被 systemd 管理，类似 UpStart 的工作配置文件。在该文件中定义服务启动的命令行语法，以及和其他服务的依赖关系等。
此外我们之前已经了解到，systemd 的功能繁多，不仅用来管理服务，还可以管理挂载点，定义定时任务等。这些工作都是由编辑相应的配置单元文件完成的。我在这里给出几个配置单元文件的例子。
下面是 SSH 服务的配置单元文件，服务配置单元文件以.service 为文件名后缀。
#cat /etc/system/system/sshd.service
[Unit]
Description=OpenSSH server daemon
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usrsbin/sshd –D $OPTIONS
ExecReload=/bin/kill –HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
文件分为三个小节。第一个是[Unit]部分，这里仅仅有一个描述信息。第二部分是 Service 定义，其中，ExecStartPre 定义启动服务之前应该运行的命令；ExecStart 定义启动服务的具体命令行语法。第三部分是[Install]，WangtedBy 表明这个服务是在多用户模式下所需要的。
那我们就来看下 multi-user.target 吧：
#cat multi-user.target
[Unit]
Description=Multi-User System
Documentation=man.systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescure.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
[Install]
Alias=default.target
第一部分中的 Requires 定义表明 multi-user.target 启动的时候 basic.target 也必须被启动；另外 basic.target 停止的时候，multi-user.target 也必须停止。如果您接着查看 basic.target 文件，会发现它又指定了 sysinit.target 等其他的单元必须随之启动。同样 sysinit.target 也会包含其他的单元。采用这样的层层链接的结构，最终所有需要支持多用户模式的组件服务都会被初始化启动好。
在[Install]小节中有 Alias 定义，即定义本单元的别名，这样在运行 systemctl 的时候就可以使用这个别名来引用本单元。这里的别名是 default.target，比 multi-user.target 要简单一些。。。
此外在/etc/systemd/system 目录下还可以看到诸如*.wants 的目录，放在该目录下的配置单元文件等同于在[Unit]小节中的 wants 关键字，即本单元启动时，还需要启动这些单元。比如您可以简单地把您自己写的 foo.service 文件放入 multi-user.target.wants 目录下，这样每次都会被默认启动了。
最后，让我们来看看 sys-kernel-debug.mout 文件，这个文件定义了一个文件挂载点：
#cat sys-kernel-debug.mount
[Unit]
Description=Debug File Syste
DefaultDependencies=no
ConditionPathExists=/sys/kernel/debug
Before=sysinit.target
[Mount]
What=debugfs
Where=/sys/kernel/debug
Type=debugfs
这个配置单元文件定义了一个挂载点。挂载配置单元文件有一个[Mount]配置小节，里面配置了 What，Where 和 Type 三个数据项。这都是挂载命令所必须的，例子中的配置等同于下面这个挂载命令：
mount –t debugfs /sys/kernel/debug debugfs
配置单元文件的编写需要很多的学习，必须参考 systemd 附带的 man 等文档进行深入学习。希望通过上面几个小例子，大家已经了解配置单元文件的作用和一般写法了。
系统管理员
systemd 的主要命令行工具是 systemctl。
多数管理员应该都已经非常熟悉系统服务和 init 系统的管理，比如 service、chkconfig 以及 telinit 命令的使用。systemd 也完成同样的管理任务，只是命令工具 systemctl 的语法有所不同而已，因此用表格来对比 systemctl 和传统的系统管理命令会非常清晰。
表 2. 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) 改变至多用户运行级别。
除了表 2 列出的常见用法，系统管理员还需要了解其他一些系统配置和管理任务的改变。
首先我们了解 systemd 如何处理电源管理，命令如下表所示：
表 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 已经不仅仅是一个初始化系统了。其替代了 sysvinit 的所有功能，但它并未就此自满。因为 init 进程是系统所有进程的父进程这样的特殊性，systemd 非常适合提供曾经由其他服务提供的功能，比如定时任务 (以前由 crond 完成) ；会话管理 (以前由 ConsoleKit/PolKit 等管理) 。仅仅从本文皮毛一样的介绍来看，Systemd 已经管得很多了，可它还在不断发展。它将逐渐成为一个多功能的系统环境，能够处理非常多的系统管理任务，有人甚至将它看作一个操作系统。
好的一点是，这非常有助于标准化 Linux 的管理！从前，不同的 Linux 发行版各行其事，使用不同方法管理系统，从来也不会互相妥协。比如如何将系统进入休眠状态，不同的系统有不同的解决方案，即便是同一个 Linux 系统，也存在不同的方法，比如一个有趣的讨论：如何让 ubuntu 系统休眠，可以使用底层的/sys/power/state 接口，也可以使用诸如 pm-utility 等高层接口。存在这么多种不同的方法做一件事情对像我这样的普通用户而言可不是件有趣的事情。systemd 提供统一的电源管理命令接口，这件事情的意义就类似全世界的人都说统一的语言，我们再也不需要学习外语了，多么美好！
如果所有的 Linux 发行版都采纳了 systemd，那么系统管理任务便可以很大程度上实现标准化。此外 systemd 有个很棒的承诺：接口保持稳定，不会再轻易改动。对于软件开发人员来说，这是多么让人感动的承诺啊！
1. 初识 Systemd
systemd是Linux系统的一套基本构建模块。它提供了一个系统和服务管理器，作为PID 1运行并启动系统的其余部分。它提供积极的并行化功能，使用套接字和D-Bus激活来启动服务，提供按需启动守护进程，使用Linux控制组跟踪进程，维护挂载和自动挂载点，并实现一个精心设计的基于事务依赖的服务控制逻辑。systemd支持SysV和LSB初始化脚本，可以替代sysvinit。
它是在引导期间启动的第一个守护进程，也是在关闭期间终止的最后一个守护进程。systemd守护进程作为用户空间进程树的根; 第一个进程(PID 1)在Unix系统上具有特殊的作用，因为当原始父进程终止时，它将替换父进程。因此第一个进程特别适合用于监视守护进程。
其他部分包括日志记录守护进程、控制基本系统配置(如主机名、日期、区域设置)的实用程序、维护登录用户和正在运行的容器和虚拟机列表、系统帐户、运行时目录和设置的实用程序，以及管理简单网络配置、网络时间同步、日志转发和名称解析的守护进程。
systemd是目前相当一部分Linux系统上主要的系统守护进程管理工具，其有如下特点：
1.支持并行化任务
2.同时采用socket式与D-Bus总线式激活服务；
3.按需启动守护进程（daemon）；
4.利用Linux的cgroups监视进程；
5.支持快照和系统恢复；
6.维护挂载点和自动挂载点；
7.各服务间基于依赖关系进行精密控制。
核心组件：
systemd
systemctl
systemd-analyze
其他组件：
kernel-install：用于自动将内核及其各自的 initramfs 映像移动到启动分区的脚本
systemd-boot：简单的UEFI引导管理器
systemd-creds：安全地存储和检索 systemd 单元使用的凭据
systemd-cryptenroll：将 PKCS#11、FIDO2、TPM2 令牌/设备注册到 LUKS2 加密卷
systemd-firstboot：首次启动前的基本系统设置初始化
systemd-homed：便携式用户帐户管理
systemd-logind：会话管理
systemd-networkd：网络配置管理
systemd-nspawn：轻量级命名空间容器
systemd-resolved：网络名称解析
systemd-stub：用于创建统一内核映像的 UEFI 引导存根
systemd-sysusers：创建系统用户和组，并在软件包安装或启动时将用户添加到组中
systemd-timesyncd：通过网络同步系统时间
systemd/Timers：用于控制 .service 文件或事件的单调或实时计时器，是 cron 的合理替代方案
systemd-journald：系统日志管理
systemd-localed： 管理系统区域设置
systemd-tmpfiles：是一个负责创建和清理临时文件和目录的实用程序。它通常在启动时运行一次，然后以指定的时间间隔运行。
Systemd可以管理所有系统资源，不同的资源统称为 Unit（单元），Unit一共分成以下12种：
1.Service：装守护进程的启动、停止、重启和重载操作，是最常见的一种 Unit 文件。描述如何管理服务或应用程序。这包括如何启动或停止服务，重新加载其配置文件，服务在什么条件下自动启动，以及相关单元文件的依赖项或层次结构信息。
2.Target：多个Unit构成的一个逻辑组，用于对 Unit 文件进行逻辑分组，引导其它 Unit 的执行。替代了 SysV-init 运行级别的作用，并提供更灵活的基于特定设备事件的启动方式。目标单元用于对单元进行分组并设置同步点以排序与其他单元文件的依赖关系。
3.Device：硬件设备，主要用于定义设备之间的依赖关系。定义已指定由 udev 或 sysfs 文件系统进行 systemd 管理的设备。
4.Mount：文件系统的挂载点，可以替代过去的 /etc/fstab 配置文件。定义系统上由 systemd 管理的挂载点。该文件以挂载路径命名，斜杠改为破折号。 /etc/fstab 中的条目可以自动创建单元。
5.Automount：自动挂载点，相当于 SysV-init 的 autofs 服务。定义自动挂载的挂载点。以它引用的挂载点命名该文件；需要匹配的 .mount 单元文件来定义安装的细节。
6.Path：用于监控指定文件或路径的变化，并触发其它 Unit 运行。定义基于路径的激活的路径。默认情况下，会激活具有相同基本名称的 .service 单元文件。
7.Scope：不是用户创建的，而是 Systemd 运行时产生的，描述一些系统服务的分组信息。该单元文件由 systemd 根据从 D-Bus 接口接收到的信息自动创建，用于管理外部创建的系统进程集。
8.Slice：进程组，用于表示一个 CGroup 的树，通常也不是用户创建的。关联Linux Control Group节点，它允许将资源分配或限制给与切片关联的任何进程。该名称表示控件树中的层次结构。根据单元的类型，单元被默认放置在切片中。
9.Snapshot：Systemd快照，可以切回某个快照。
10. Socket：监控来自于系统或网络的数据消息，用于实现基于数据自动触发服务启动。描述 systemd 用于基于套接字激活的网络、IPC 套接字或 FIFO 缓冲区。当在该单元定义的套接字上看到活动时，会启动一个关联的 .service 文件。
11. Swap：虚拟内存的交换分区。定义系统上的交换空间，单元文件的名称必须反映空间的设备或文件路径。
12. Timer Unit：定时器，用于配置在特定时间触发的任务，替代了 Crontab 的功能。定义由 systemd 管理的计时器。这类似于用于延迟或计划激活的 cron 任务；当计时器到达时，将启动具有相同名称但文件扩展名为 .service 的单元文件。
2. Systemd Service配置文件
每一个被管理单元（Unit）都需要有一个配置文件用于告知systemd对于该单元（Unit）的管理方式。Systemd默认从目录/etc/systemd/system/读取配置文件，但是里面存放的大部分文件都是符号链接，指向目录/lib/systemd/system，配置文件存放于/lib/systemd/system/，开机启动后会在/etc/systemd/system目录建立软链接文件，systemctl enable命令用于在/etc/systemd/system/与/lib/systemd/system/两个目录之间建立符号链接关系。systemctl disable命令用于在两个目录之间撤销符号链接关系，相当于撤销开机启动。配置文件的后缀名，就是该Unit的种类，比如sshd.socket；如果命令行中省略后缀名，Systemd默认后缀名为.service，所以当systemctl enable sshd会被理解成systemctl enable sshd.service。
以sshd.service的配置为例，可用”systemctl cat sshd.service” 命令查看sshd服务的配置文件：
# /lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
Alias=sshd.service
通常一个service服务单元的配置包含3个区块：Unit，Service和Install。
关于 $MAINPID
$MAINPID is a systemd variable for your service that points to the PID of the main application.
$MAINPID是服务的systemd变量，它指向主应用程序的PID。但有些场景下取的不准确或者取到同类其它进程号去了。
2.1 Unit区块
[Unit]区块通常是配置文件的第一个区块，用来定义 Unit 的元数据，以及配置与其他 Unit 的关系。它的主要字段如下：
Description：对该服务的描述
Documentation：文档地址
Requires：本unit需要在哪个服务启动后才能够启动！这里设置服务间的依赖性。如果在此项设置的前导服务没有启动成功，那么本 unit 就不会被启动！
Wants：与Requires 刚好相反，规范的是这个unit之后还会启动什么服务，如果这Wants 后面接的服务如果没有启动成功，不会影响到这个unit本身！
BindsTo：与Requires类似，它指定的 Unit 如果退出，会导致当前Unit停止运行
Before：如果该字段指定的Unit也要启动，那么必须在当前Unit之后启动；与After的意义相反
After：如果该字段指定的Unit也要启动，那么必须在当前Unit之前启动；说明本unit是在哪个服务后启动。仅是说明服务启动的顺序而已，并没有强制要求。
Conflicts：这个项目后面接的服务如果有启动，那么本unit就不能启动！（互斥性） 如果本unit启动了，则指定的服务就不能启动
Condition...：当前Unit运行必须满足的条件，否则不会运行
Assert...：当前Unit运行必须满足的条件，否则会报启动失败
2.2 Service区块
[Service]区块用来Service的配置，只有Service类型的Unit才有这个区块。它的主要字段如下：
Type：定义启动时的进程行为。它有以下几种值。
Type=simple：默认值，执行ExecStart指定的命令，启动主进程
Type=forking：以fork方式从父进程创建子进程，创建后父进程会立即退出
Type=oneshot：一次性进程，Systemd会等当前服务退出，再继续往下执行
Type=dbus：当前服务通过D-Bus启动
Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行
Type=idle：若有其他任务执行完毕，当前服务才会运行
ExecStart：启动当前服务的命令
ExecStartPre：启动当前服务之前执行的命令
ExecStartPost：启动当前服务之后执行的命令
ExecReload：重启当前服务时执行的命令
ExecStop：停止当前服务时执行的命令
ExecStopPost：停止当其服务之后执行的命令
RestartSec：自动重启当前服务间隔的秒数
Restart：定义何种情况Systemd会自动重启当前服务，可能的值包括always（总是重启）、on-success、on-failure、on-abnormal、on-abort、on-watchdog
TimeoutSec：定义Systemd停止当前服务之前等待的秒数
Environment：指定环境变量
KillMode：服务停止类型，默认control-group停止时杀死所有子进程，process只杀主进程，none只停止服务，不杀进程；定义 Systemd 如何停止 sshd 服务。它可以设置的值如下：
- control-group（默认值）：当前控制组里面的所有子进程，都会被杀掉
- process：只杀主进程
- mixed：主进程将收到 SIGTERM 信号，子进程收到 SIGKILL 信号
- none：没有进程会被杀掉，只是执行服务的 stop 命令
Restart：服务重启类型，默认no不重启，on-success正常退出时重启，on-failure非正常退出时重启，Restart扩展：定义了 sshd 退出后，Systemd 的重启方式。它可以设置的值如下：
- no（默认值）：退出后不会重启
- on-success：只有正常退出时（退出状态码为0），才会重启
- on-failure：非正常退出时（退出状态码非0），包括被信号终止和超时，才会重启
- on-abnormal：只有被信号终止和超时，才会重启
- on-abort：只有在收到没有捕捉到的信号终止时，才会重启
- on-watchdog：超时退出，才会重启
- always：不管是什么退出原因，总是重启
注意：对于守护进程，推荐设为on-failure。对于那些允许发生错误退出的服务，可以设为on-abnormal。
RestartSec：间隔多久重启服务。 例如RestartSec=42s
TimeoutSec：若这个服务在启动或者是关闭时，因为某些缘故导致无法顺利 “正常启动或正常结束” 的情况下，则我们要等多久才进入 “强制结束” 的状态！
RemainAfterExit：当设置为 RemainAfterExit=1 时，则当这个服务所属的所有程序都终止之后，此服务会再尝试启动。这对于 Type=oneshot 的服务很有帮助！
EnvironmentFile：通过文件的方式设置环境变量
user：可以设置服务的用户名
2.3 Install区块
[Install]通常是配置文件的最后一个区块，用来定义如何启动，以及是否开机启动。它的主要字段如下:
WantedBy：它的值是一个或多个Target，当前Unit激活时（enable）符号链接会放入/etc/systemd/system目录下面以Target名+.wants后缀构成的子目录中
RequiredBy：它的值是一个或多个Target，当前Unit激活时，符号链接会放入/etc/systemd/system目录下面以Target 名 + .required后缀构成的子目录中
Alias：当前Unit 可用于启动的别名
Also：当前Unit激活（enable）时，会被同时激活的其他Unit
系统的.target的文件信息主要字段含义如下：
Requires：要求basic.target一起运行
Conflicts：冲突字段。如果rescue.service或rescue.target正在运行，multi-user.target就不能运行，反之亦然
After：表示multi-user.target在basic.target 、 rescue.service、 rescue.target之后启动，如果它们有启动的话
AllowIsolate：允许使用systemctl isolate命令切换到multi-user.target
3. 服务监控启动
3.1 socket 触发的服务
涉及网络的服务，可以通过 socket 来触发启动。也就是说服务本身在没连接业务时不用一直空跑着，可以让systemd 帮忙监听一个 socket，以减少资源消耗。当真正有业务连接进来时，才唤醒目标服务。要达成这样的配置，目标服务程序在实现上也有一定要求。
开发一个常规的网络服务，一般有以下几个关键步骤：
1.创建一个 socket
2.调用 bind 将该 socket 绑定一个端口
3.调用 listen 监听端口，将该 socket 变成监听文件描叙符 fd
4.调用 accept 接收一个客户端连接，得到一个新的连接文件描叙符 fd
5.读写连接 socket 的 fd，完成业务逻辑
借助 systemd 强大且通用的服务功能，它可以帮忙完成前两步，并且将 socket 的 fd 传给被激活的程序，后者就只要从第3步开始实现工作。由socker触发的服务对应于 systemd 的配置文件要有两个，后缀分别是.socket与.service ，除后缀外的文件名要相同，这样就能自动关联，例如名为hello-world-socket的服务：
hello-world-socket.socket
[Unit]
Description=Hello World Socket
[Socket]
ListenStream=0.0.0.0:1234
hello-world-socket.service
[Unit]
Description=Hello World Socket Service
[Service]
ExecStart=/absolute/path/to/hello-world-socket.exe
如上，.socket 的配置，需要有 [Socket] 段，ListenStream 字段表示了要监听的地址与端口。相应的 .service 配置，与之前例子一样，描叙了如何启动服务。因为这是想由 socket 激活的 service ，故没有配置重启字段。
在 systemctl 的大多数子命令中，如 start ，其参数默认是假定 .service 单元配置的。例如systemctl start hello-world-socket 等效于 systemctl start hello-world-socket.service 。但在这个例子中，有两种同名单元配置，且按要求先只启动 hello-world-socket.socket ，所以要写完整的单元名：
systemctl start hello-world-socket.socket
3.2 定时器触发的服务
对于定时器触发的服务首先要配置一个 .timer 单元文件，例如：
hello-world.timer
[Unit]
Description=The Hello-World Timer
[Timer]
OnCalendar=*-*-* *:*:00
其中 OnCalendar 的配置格式同 crontab ，上例表示每分钟触发。然后需要一个同名的 .service 单元文件。本文开头编译的 hello-world.exe 正好 可作为该定时器启动的程序，例如：
hello-world.service
[Unit]
Description=The Hello-World Timer
[Service]
Type=oneshot
ExecStart=/absolute/path/to/hello-world.exe
StandardOutput=file:/absolute/path/to/stdout-file
然后启动定时器，并查看状态：
systemctl start hello-world.timer
systemctl status hello-world.timer
4. 服务异常重运行
为了确保服务在遭遇故障时能够自动重启。在Systemd的服务单元文件中，Restart指令是控制服务重启行为的核心设置。这里将探讨Restart=on-failure与Restart=always这两个选项的区别，以帮助开发人员对系统服务做出更适合的选择。Restart指令定义了当服务停止时Systemd的行为。它可以精细控制服务在遇到不同退出情况时是否应该重启。这是确保关键服务可靠性的重要机制，尤其是在生产环境中，服务的持续运行对业务至关重要。
4.1 Restart=on-failure：智能重启
当服务单元文件中设置了Restart=on-failure时，Systemd会在服务因错误退出时尝试重启服务。"错误退出"通常是指服务以非零状态码结束运行，这可能是由于程序崩溃、遇到未处理的异常或其他非正常情况导致的。例如，如果你的服务由于内存不足而崩溃，on-failure将确保服务尝试重新启动。但如果服务是由于正常的系统维护任务而被停止，或者开发人员故意停止服务进行调试，那么它将不会被重启。
其应用场景如下：
生产环境：在不希望因为维护或更新操作而自动重启服务的生产环境中使用。
故障排除：当服务可能需要在出现问题时停止，以便进行故障排除时。
有条件的重启：当你只想在服务因特定问题而停止时重启。
4.2 Restart=always：无条件重启
与on-failure相对的是Restart=always选项。不管服务是如何终止的，系统都会尝试将其重启。这意味着即使服务被管理员有意关闭，或者服务正常结束，Systemd也会立即尝试将其重启。
这种策略适用于那些必须始终运行的服务，无论它们是因为何种原因停止的。这确保了即使在进行系统更新或维护时，服务也能尽可能快地恢复运行。
其应用场景如下：
关键服务：对于那些系统的核心功能，如数据库服务或Web服务器，这些服务的任何停机时间都是不可接受的。
高可用性要求：在需要最大程度减少服务停机时间的环境中。
5. 常用命令使用参考
5.1 systemctl命令的用法
注意：PATTERN、UNIT等其他的变量值后面带...，表示可以传递多个，用空格隔开
UNIT单元不用写后缀，如.service、.target等，systemd会根据子命令的类型自动推断后缀，如下：
systemctl start sshd
与 systemctl start sshd.service 对等
systemctl isolate default
与 systemctl isolate default.target 对等
单元命令
list-units [PATTERN…]：此为默认命令，即 只使用systemctl调用的也是此命令。
列出systemd当前在内存中的单元。这包括直接引用或通过依赖项引用的单元，由应用程序以编程方式固定的单元，或者过去活跃但失败的单元。
默认情况下，只显示活动的、有待处理任务或失败的单元; 可以通过选项--all进行更改。
注意，这个命令不显示单元模板，而只显示单元模板的实例。未实例化的单元模板是不可运行的，因此永远不会出现在该命令的输出中。
具体来说，这意味着foo@.Service永远不会显示在这个列表中——除非实例化，例如foo@bar.service。使用list-unit-files列出已安装的单元模板文件。
pattern要接单元类型后缀，如：systemctl list-units nginx.service
示例：systemctl list-units 列出所有单元
systemctl list-units nginx.service 指定单元
LOAD字段可能的值有：loaded, not-found, bad-setting, error, masked;
ACTIVE字段可能的值有：active, reloading, inactive, failed, activating, deactivating。
is-active [PATTERN…]：检查指定的单元是否是激活状态
示例：systemctl is-active nginx php-fpm
is-failed [PATTERN…]：检查指定的单元是否是失败状态
示例：systemctl is-failed nginx php-fpm
status [PATTERN…|PID…]]：显示单元的运行时状态信息，如果不接单元名或进程id，则显示整个系统单元的状态信息，整个系统单元的状态会以树状结构来显示输出。
示例：
systemctl status
systemctl status nginx php-fpm
systemctl status 924，924是PID，此时对应的是php-fpm进程
status命令输出人类可读的格式文本，如果想要输出计算机可解析的格式，则使用show命令代替。status命令只显示正在运行，或最近运行过并尚未从内存中释放的单元的信息，要获取早期运行过的单元日志信息，使用journalctl命令获取。
Loaded：配置文件的位置，是否设为开机启动，disabled代表启用
Active：active (running) 表示正在运行
Main PID：主进程ID
CGroup：应用的所有子进程，三个nginx进程
日志块：应用的日志
注意：status命令会隐式加载单元，如果以此返回的状态信息来判断单元是否已经被加载有时是不准确的，因为隐式加载后可能随后就会快速取消加载。
图标的颜色和形状表示的状态：
“未激活”或“维护”是一个白色圆圈(“〇”)，“激活”是一个绿色圆点(“●”)，“停用”是一个白点，“失败”或“错误”是一个红色的十字(“x”)，“重新加载”是一个绿色的顺时针圆形箭头("↻")。
show [PATTERN…|JOB…]：
显示一个或多个单元、任务或systemd本身的属性。如果没有指定参数，将显示systemd的属性。如果指定了单元名称，则显示单元的属性; 如果指定了任务ID，则显示任务的属性。默认情况下，空属性将被抑制。使用--all来显示这些。要选择要显示的特定属性，使用--property=来指定。该命令用于任何需要计算机可解析输出的情况。
示例：
systemctl show
systemctl show nginx
cat PATTERN…：显示单元的配置文件内容，每个文件前面都有一个包含文件名的注释，如果磁盘上的任何单元文件被更新，并且没有发出daemon-reload命令，此时显示的配置文件内容不是最新的。
示例：systemctl cat nginx php-fpm
help PATTERN…|PID…：显示指定单元的手册页，也可传PID，当然如果在配置中没有定义手册这一项，则不会输出。
示例：systemctl help nginx
list-dependencies [UNIT...]：显示指定单位所需和想要的依赖单位。这将递归列出遵循 Requires=、Requisite=、Wants=、ConsistsOf=、BindsTo= 和 Upholds= 依赖项的单元。如果未指定单位，则默认是default.target。默认情况下，仅递归扩展目标单元。当--all 被传递时，所有其他单元也会递归扩展。
示例：
systemctl list-dependencies
systemctl list-dependencies nginx
start PATTERN…：启动单元，或者叫激活指定的单元，可以传--all启动所有单元
示例：
systemctl start nginx php-fpm
systemctl start --all
stop PATTERN…：停止单元，或者叫停用指定的单元
如果单元不存在或已经停止则会操作失败；如果单元配置了ExecStop=选项，则stop命令不会失败，因为systemd将会强制终止单元。
示例：systemctl stop nginx php-fpm
reload PATTERN…：重新加载单元里面指定的服务进程配置文件，例如：nginx、php-fpm的自身的配置文件，不是systemd的单元配置文件。
示例：systemctl reload nginx php-fpm
restart PATTERN…：重启指定的单元，内部逻辑为：先停止后启动，如果单元没有在运行，则只会启动。注意此命令是平滑重启，单元储存的资源会保留，只要单元有一个待办的任务，并且只有在单元完全停止并且不再有任务待办时才会被清除。
示例：systemctl restart nginx php-fpm
try-restart PATTERN…：停止然后启动指定的单元且仅仅在单元是运行状态时，如果单元不在运行，则不做任何操作。
示例：systemctl try-restart nginx php-fpm
reload-or-restart PATTERN…：如果单元支持重载配置，即配置了ExecReload选项时，则执行重载操作，否则执行重启操作；如果单元没有在运行，则执行启动操作。
示例：systemctl reload-or-restart nginx php-fpm
try-reload-or-restart PATTERN…：与reload-or-restart相似，不同的是当单元没有在运行，则不执行任何操作。
示例：systemctl try-reload-or-restart nginx php-fpm
isolate [UNIT]：启动指定的单元及其依赖项并停止所有其他单元，除非它们具有 IgnoreOnIsolate=yes选项。如果给出的单元名称没有扩展名，则将假定扩展名为“.target”。
此命令很危险，因为它会立即停止新目标中未启用的进程，可能包括当前正在使用的图形环境或终端。此命令仅在启用了AllowIsolate的设备上才允许执行此操作。
示例：systemctl isolate nginx
freeze PATTERN…：冻结指定的单元
冻结该单元将导致cgroup中与该单元对应的所有进程被挂起。被挂起意味着单元的进程在解冻之前不会被安排在CPU上运行。注意该命令仅支持使用统一cgroup层次结构的系统。单元在我们对单元执行作业之前自动解冻，例如，在单元停止之前。
示例：systemctl freeze nginx php-fpm
thaw PATTERN…：解冻指定的单元
这是 freeze 命令的逆操作，恢复单元 cgroup 中进程的执行。
示例：systemctl thaw nginx php-fpm
set-property UNIT PROPERTY=VALUE…：
在运行时设置支持的指定单元属性。这允许在运行时更改配置参数属性，例如资源控制设置。并非所有属性都可以在运行时更改，但是许多资源控制设置可以。这些更改将立即应用，并存储在磁盘上以备以后的引导，
除非传递了--runtime参数，在这种情况下，这些设置只应用到下一次重新引导。如果指定的单元处于非活动状态，则更改将仅存储在磁盘上，因此它们将在单元启动时生效。
示例：systemctl set-property foobar.service CPUWeight=200
可以一次性设置多个属性
示例：systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes
与单元文件配置设置一样，分配空设置通常会将属性重置为其默认值
示例：systemctl set-property avahi-daemon.service IPAddressDeny=
单元文件相关的命令
list-unit-files [PATTERN…]：列出系统上安装的单元文件，连同它们的启用状态，与 list-units 不同，此命令除了显式实例化的单元外还将列出模板单元。
enable UNIT…, enable PATH…：
启用一个或多个单元或单元实例。
将创建一组符号链接，在创建了符号链接之后，系统管理器配置将被重新加载(在某种程度上相当于daemon-reload)，这并不会同时启动任何已启用的单元，只是systemd读取到了此单元，可以在systemd开机自启时自动启动，如果需要启用后立马启动，则可以接--now，内部调用start命令启动。
示例：systemctl enable nginx php-fpm
disable UNIT…：
禁用一个或多个单位，使得不能在开机时自动启动。这将从单元配置目录中删除到支持指定单元的单元文件的所有符号链接，并因此撤消由enable或link所做的任何更改。
除了指定的单元外，此单元文件的 [Install] 部分中包含的 Also= 设置中列出的所有单元均被禁用。该命令在完成操作后隐式地重新加载系统管理器配置，即执行daemon-reload。注意该命令不会隐式停止正在禁用的单元。如果需要这样做，可以将该命令与--now开关结合使用，内部调用了stop命令。
示例：systemctl disable nginx php-fpm
reenable UNIT…：
重新启用一个或多个单元。这是disable和enable的组合，用于将单元文件启用的符号链接重置为[Install]节中配置的默认值。这个命令只需要单元名，它不接受单元文件的路径。
示例：systemctl reenable nginx php-fpm
is-enabled UNIT…：检查指定的单元是否是启用状态
示例：systemctl is-enabled nginx php-fpm
mask UNIT…：
屏蔽指定的单元。这将把这些单元文件链接到/dev/null，使它们无法启动。这是一个更强的disable版本，因为它禁止所有类型的单元激活，包括启用和手动激活。
请谨慎使用此选项。这允许--runtime选项暂时屏蔽，直到下次重新启动系统。--now选项可用于确保单元也被停止。这个命令只需要有效的单元名，它不接受单元文件路径。
示例：systemctl mask nginx php-fpm
unmask UNIT…：取消屏蔽指定的单元。
示例：systemctl unmask nginx php-fpm
revert UNIT…：撤销或者叫还原指定单元的配置到厂商原配置
将指定单元文件还原到它们的供应商版本。该命令删除修改指定单元的插入式配置文件，以及覆盖匹配供应商提供的单元文件的任何用户配置的单元文件。
具体来说，对于一个单元“foo.service“匹配的目录”foo.service.d/"及其包含的所有文件被删除，包括持久配置目录和运行时配置目录(即/etc/systemd/system和/run/systemd/system)下的文件;
同样，如果一个单元被屏蔽，它将被解除屏蔽。实际上此命令可用于撤消使用 systemctl edit、systemctl set-property 和 systemctl mask 所做的所有更改，并使原始单元文件及其设置重新生效。
示例：systemctl revert nginx php-fpm
edit UNIT…：编辑单元文件，用来扩展或覆写原来的单元文件
根据是否指定了--system(默认值)、--user或--global，该命令将为系统、调用用户或所有用户的所有未来登录的每个单元创建一个插入文件。然后，在临时文件上调用编辑器，如果编辑器成功退出，这些临时文件将被写入实际位置。
如果指定了--drop-in=[filename]，则将使用给定的 drop-in 文件名而不是默认的 override.conf。
如果指定了--full，将复制原始单元文件而不是创建嵌入式文件。
如果指定了--force，并且任何单位尚不存在，则将打开新的单位文件进行编辑。
如果指定了--runtime，则更改将暂时在 /run/ 中进行，并且它们将在下次重新启动时丢失。
如果退出时临时文件为空，则取消相关单元的修改。编辑单元后，将重新加载 systemd 配置（以相当于调用了daemon-reload）。
示例：systemctl edit nginx php-fpm
get-default：获取默认target的单元名称，实际上是default.target的符号链接。
示例：systemctl get-default
set-default TARGET：设置默认的target，实际上是将default.target的符号链接设置为指定的目标单元
示例：systemctl set-default multi-user.target
机器命令
list-machines [PATTERN…]：列出主机和所有正在运行的本地容器及其状态。
示例：systemctl list-machines
任务命令
list-jobs [PATTERN…]：列出正在进行的任务
示例：systemctl list-jobs
cancel [JOBID…]：取消指定的任务，通过任务id来指定，如果没有指定任务id，则取消所有待处理的任务。
示例：systemctl cancel 1608941
管理器状态命令
daemon-reload：
重新加载systemd管理器配置，重新加载所有单元文件，并重新创建整个依赖树。
示例：systemctl daemon-reload
系统命令
is-system-running：检查systemd系统是否正在运行
示例：systemctl is-system-running
输出的值有如下几种：
initializing：正在初始化
starting：正在启动
running：正在运行
degraded：系统正在运行，但一个或多个单元出现故障。
maintenance：系统处于维护模式
stopping：系统正在停止
offline：系统已经离线
unknown：未知错误，由于缺乏资源或其他错误原因，无法确定操作状态。
default：进入默认模式，相当于调用了 systemctl isolate default.target
示例：systemctl default
rescue：进入拯救模式，相当于调用了 systemctl isolate rescue.target
示例：systemctl rescue
emergency：进入紧急模式，相当于调用了 systemctl isolate emergency.target
示例：systemctl emergency
halt：关闭并停止系统，但硬件还是处于开机状态，相当于调用了 systemctl start halt.target。
如果接 --force，则强制停止系统，所有进程将被杀死。如果接 --when=，when指定时间戳，则在指定的时间戳之后停止系统，如果--when=cancel，则取消关闭系统的操作。
示例：systemctl halt
poweroff：停止系统并关机，硬件处于关机状态，相当于调用了 systemctl start poweroff.target。也可接 --force和--when，行为与上述相似
示例：systemctl poweroff
reboot：关闭并重新启动系统，相当于调用了 systemctl start reboot.target。也可以接 --force和--when，行为与上述相似
示例：systemctl reboot
suspend：暂停或者叫挂起系统，内部会触发调用 suspend.target
示例：systemctl suspend
hibernate：使系统休眠，内部会触发调用 hibernate.target
示例：systemctl hibernate
hybrid-sleep：休眠并挂起系统，内部会触发调用 hybrid-sleep.target
示例：systemctl hybrid-sleep
常用的选项
-t, --type=：显示指定类型的单元，多个类型用逗号隔开；例如指定为service、socket，多用于 list-units, list-dependencies, show, status 子命令。注意如果指定 -t help，则打印出所有可用的类型值
示例：systemctl status -t service
--state=：显示指定状态的单元，多个状态用逗号隔开；例如指定为failed、active，多用于 list-units, list-dependencies, show, status
示例：systemctl status --state=failed
-p, --property=：显示指定的unit/job/manager的属性，多个属性名用逗号隔开；例如：MainPID
示例：systemctl show -p LogLevel
-a, --all：
用途场景如下：
当使用 list-units 列出单位时，还显示非活动单位和跟随其他单位的单位。
当显示单位/任务/manager属性时，显示所有属性，无论是否设置。
当显示单位的依赖时：list-dependencies，递归地显示所有依赖单元的依赖关系。
当与status一起使用时，显示完整的日志消息，即使它们包含不可打印的字符。
示例：
systemctl list-units -a
--with-dependencies：
当与 status、cat、list-units 和 list-unit-files 一起使用时，这些命令会打印所有指定的单元以及这些单元的依赖关系。
示例：
systemctl status --with-dependencies
-q, --quiet：
禁止打印各种命令的结果以及关于截断的日志行的提示。但错误总是打印出来。
示例：systemctl start nginx -q
--no-warn：抑制警告信息
示例：systemctl start nginx --no-warn
--no-block：不同步等待请求的操作完成。
使systemd耗时的操作变为异步，此选项与 --wait 选项互斥。
示例：systemctl default --no-block
--wait：同步等待请求的操作完成。与 --no-block 互斥。
示例：systemctl default --wait
-f, --force：强制操作
使用场景如下：
使用 enable 时，覆盖掉任何已存在冲突的符号链接
使用 edit 时，如果指定的单元不存在，则自动创建
在使用 halt, poweroff, reboot时，会强制关闭系统，强制杀死进程。
-o, --output=：控制在使用 status 时的输出格式，详情参考下方 journal的说明。
示例：systemctl status -o short-iso
--plain：当在使用 list-dependencies, list-units, list-machines 时，输出为列表的形式而不是树形结构。
示例：systemctl list-units --plain
-h, --help：打印帮助信息
示例：systemctl -h
--version：打印版本号
systemctl --version
5.2 journalctl常用选项的用法
如果不带参数调用，它将显示调用用户可访问的日志内容，从最早的历史日志开始显示，所以内容多的话会很卡，一般无参调用。
--system, --user：显示来自系统服务和内核的消息（使用 --system）。显示来自当前用户服务的消息（使用 --user）。如果两者均未指定，则显示用户可以看到的所有消息。
示例：journalctl --user
-u, --unit=UNIT|PATTERN：指定服务单元名称，或单元匹配模式，此选项可使用多次。
示例：journalctl -u nginx
-p, --priority=：通过优先级过滤日志信息，可指定单个日志级别或范围级别。
日志有8个级别，可用数字表示，也可用文本表示，如下：
emerg(Emergency): 0, // 紧急，表示系统无法使用，需要立即处理。
alert(Alert): 1, // 警报，表示需要立即采取行动来解决关键问题。
crit(Critical): 2, // 严重，表示程序中需要干预以防止系统故障的关键条件。
err(Error): 3, // 错误，表示影响某些操作但不如紧急情况严重的错误情况。
warning(Warning): 4, // 警告，表示如果不解决，将来可能会导致错误或意外行为的潜在问题。
notice(Notice): 5, // 注意，适用于可能需要监测的正常但重要的情况。
info(Informational): 6, // 信息，包括提供系统正常运行记录的消息。
debug(Debug): 7 // debug信息，用于记录有关系统的详细信息以进行调试。
如果指定的是单个级别，则会显示小于等于指定级别的日志信息，例如：指定的是4，则显示 <=4 的日志信息；如果指定的是级别范围，格式为：FROM..TO，之间是两个点，则会显示包括开始和结束边界值的日志信息，例如：指定 1..4，则显示1、2、3、4的日志信息。
示例：
journalctl -p 4
journalctl -p 1..4
-g, --grep：使用正则表达式匹配过滤
如果模式字符串全小写，则匹配是不区分大小写的，否则是区分的，也可以接--case-sensitive覆盖此行为。
示例：journalctl -g ^ng
--case-sensitive[=BOOLEAN]：接上，指定匹配是否区分大小写，值为：true或false。
示例：journalctl -g ^nG --case-sensitive=true
-k, --dmesg：仅仅显示内核日志信息，此选项相当于隐式使用了 -b，和添加了 _TRANSPORT=kernel。
示例：journalctl -k
-o, --output=：控制日志的输出格式，有如下多个格式可选：
short：此为默认格式，生成的输出与经典系统日志文件的格式基本相同，每个日志条目显示一行。
short-full：与short显示的时间戳信息不同，此模式在输出中包含工作日、年份和时区信息，并且与语言环境无关。
short-iso：时间戳显示的ISO 8601的时间格式，如：2024-04-30T01:23:38+0800。
short-iso-precise：与short-iso相似，但包含完整的微秒部分。
short-precise：与short相似，但包含完整的微秒部分。
short-unix：与short相似，但显示的是unix时间戳，自 UTC 1970年1月1日以来经过的秒数，并包含微秒部分。
verbose：显示完整结构的日志信息。
json：显示成json格式，一条记录一行。
如果字段超过4096个字节，将会编码为null值，但可接 --all来取消这个默认行为。
日志条目允许同一日志条目中存在非唯一字段。 JSON 不允许对象内存在非唯一字段。因此，如果遇到非唯一字段，则会使用 JSON 数组作为字段值，将所有字段值列出为元素。包含不可打印或非 UTF8 字节的字段被编码为包含单独格式化为无符号数字的原始字节的数组。
json-pretty：美化输出json格式，每个字段占一行。
cat：生成一个简洁的输出，仅仅显示日志本身的信息，不附带元数据和时间戳。
with-unit：与short-full类似，但前缀为单元和用户单元名称，而不是传统的syslog标识符。使用模板化实例时很有用，因为它将在单元名称中包含参数。
--output-fields=：指定日志信息输出的字段，多个用逗号隔开，只对显示所有字段的输出模式有效，包括：verbose, export, json, json-pretty, json-sse, json-seq, cat。
可用的字段参考json格式输出的字段。
示例：journalctl -u nginx -o json-pretty --output-fields=PRIORITY,__CURSOR
-r, --reverse：反转输出，最新的日志展示在上面。
-a, --all：完整显示所有字段，即使它们包含不可打印的字符或非常长。默认情况下，具有不可打印字符的字段缩写为“blob data”。
-f, --follow：仅仅显示最新的日志，只要有新日志追加进来则一直打印输出，与tail -f 相似。
-q, --quiet：禁止所有信息性消息（即“-- Journal begins at”、“-- Reboot --”）以及以普通用户身份运行时有关无法访问的系统日志的任何警告消息。
--disk-usage：显示所有日志文件的当前磁盘使用情况。这显示了所有已归档和活动日志文件的磁盘使用量总和。
-h, --help：打印帮助信息
--version：打印版本号
5.3 其他组件的用法
hostnamectl
可用于打印主机名、图标名、设备类型、机器ID、操作系统类型、内核及其架构类型等等。
systemd-analyze
使用systemd-analyze命令可以分析系统启动过程的性能。该命令还可用于从系统和服务管理器检索其他状态和跟踪信息。它用于检查单元文件是否正确，也用于访问高级系统管理器调试有用的特殊功能。
例如：查看系统启动所需的时间
systemd-analyze time
Startup finished in 3.404s (kernel) + 2.415s (initrd) + 13.125s (userspace) = 18.945s
graphical.target reached after 13.117s in userspace
获得服务启动过程的高级概述，其中包括启动的服务和每个服务启动所需的时间
systemd-analyze critical-chain
该命令为每个指定的单元或默认目标打印时间关键单元树。查看服务启动过程中启动的服务列表，并显示每个服务所花费的时间。
systemd-analyze blame
可用使用systemd-analyze生成一个矢量图形文件，显示启动过程中发生的事件
systemd-analyze plot > /temp/sample.svg
LibreOffice Draw 等应用程序可以使用这些向量来生成图形。
使用 systemd-analyze verify 检查 systemd 单元文件的语法
systemd-analyze verify /etc/systemd/system/my-custom-service.service
该命令分析单元文件并报告任何语法错误、丢失文件或其他问题。
6、简单判断当前的Linux操作系统是否使用了systemd来作为初始系统
1.检查进程号为1的进程
毕竟，init系统是Linux操作系统上运行的第一个进程。
ps 1
通过输出结果会发现通常会指向/sbin/init，通过该（符号链接或文件）就可以获得init系统信息，可以使用指令：
1).stat
2).readlink
# stat /sbin/init
输出一：使用了sysvinit的init的情况
文件：/sbin/init
大小：52240 块：104 IO 块：4096 普通文件
设备：801h/2049d Inode：50332049 硬链接：1
权限：(0755/-rwxr-xr-x) Uid：( 0/ root) Gid：( 0/ root)
最近访问：2024-12-08 21:30:33.723266301 +0800
最近更改：2021-04-24 17:41:23.000000000 +0800
最近改动：2021-10-24 21:00:10.916002352 +0800
创建时间：2021-10-24 21:00:10.900002351 +0800
输出二：使用了systemd的init系统的情况
文件：/sbin/init -> /lib/systemd/systemd
大小：20 块：0 IO 块：4096 符号链接
设备：803h/2051d Inode：805307368 硬链接：1
权限：(0777/lrwxrwxrwx) Uid：( 0/ root) Gid：( 0/ root)
最近访问：2024-10-15 18:53:31.483460146 +0800
最近更改：2022-08-07 21:25:09.000000000 +0800
最近改动：2022-11-21 01:15:30.617588015 +0800
创建时间：2022-11-21 01:15:30.477588011 +0800
如果是链接，可通过'readlink /sbin/init'来查看实际文件的位置。
如果系真实文件而非链接文件，可用'readlink -f /sbin/init'查看到实际文件的路径信息。
结束语
本系列文章从古老却简明稳定的 sysvinit 说起，接着简要描述了 UpStart 带来的清新改变，最后看到了充满野心和活力的新生代 systemd 系统逐渐统治 Linux 的各个版本。就好像在看我们这个世界，一代人老去，新的一代带着横扫一切的气概登上舞台，还没有喊出他们最有力的口号，更猛的一代已经把聚光灯和所有的目光带走。Systemd 之后也许还有更新的 init 系统出现吧，让我们继续期待。。。
本文源自IBM DeveloperWorks 中文社区，作者：刘明