1. Systemd 简介

Systemd是什么，以前linux系统启动init机制，由于init一方面对于进程的管理是串行化的，容易出现阻塞情况，另一方面init也仅仅是执行启动脚本，并不能对服务本身进行更多的管理。Systemd就是为了解决这些问题而诞生的。它的设计目标是，为系统的启动和管理提供一套完整的解决方案，根据Linux惯例，字母d是守护进程（daemon）的缩写，Systemd这个名字的含义，就是它要守护整个系统。使用了Systemd，就不需要再用init了。Systemd取代了initd，成为系统的第一个进程（PID 等于 1），其他进程都是它的子进程。

Systemd是目前Linux系统上主要的系统守护进程管理工具，有如下特点：

1.支持并行化任务

2.同时采用socket式与D-Bus总线式激活服务；

3.按需启动守护进程（daemon）；

4.利用Linux的cgroups监视进程；

5.支持快照和系统恢复；

6.维护挂载点和自动挂载点；

7.各服务间基于依赖关系进行精密控制。

Systemd可以管理所有系统资源，不同的资源统称为 Unit（单元）,Unit一共分成以下12种。

1.Service：装守护进程的启动、停止、重启和重载操作，是最常见的一种 Unit 文件

2.Target：多个Unit构成的一个逻辑组，用于对 Unit 文件进行逻辑分组，引导其它 Unit 的执行。它替代了 SysV-init 运行级别的作用，并提供更灵活的基于特定设备事件的启动方式

3.Device：硬件设备，主要用于定义设备之间的依赖关系

4.Mount：文件系统的挂载点，可以替代过去的 /etc/fstab 配置文件

5.Automount：自动挂载点，相当于 SysV-init 的 autofs 服务

6.Path：用于监控指定文件或路径的变化，并触发其它 Unit 运行

7.Scope：不是用户创建的，而是 Systemd 运行时产生的，描述一些系统服务的分组信息

8.Slice：进程组，用于表示一个 CGroup 的树，通常也不是用户创建的

9.Snapshot：Systemd快照，可以切回某个快照

10. Socket：监控来自于系统或网络的数据消息，用于实现基于数据自动触发服务启动

11. Swap：虚拟内存的交换分区

12. Timer Unit：定时器，用于配置在特定时间触发的任务，替代了 Crontab 的功能

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。

2.1Unit区块

[Unit]区块通常是配置文件的第一个区块，用来定义 Unit 的元数据，以及配置与其他 Unit 的关系。它的主要字段如下：

Description：简短描述

Documentation：文档地址

Requires：当前Unit依赖的其他Unit，如果它们没有运行，当前Unit会启动失败

Wants：与当前Unit配合的其他Unit，如果它们没有运行，当前Unit不会启动失败

BindsTo：与Requires类似，它指定的 Unit 如果退出，会导致当前Unit停止运行

Before：如果该字段指定的Unit也要启动，那么必须在当前Unit之后启动

After：如果该字段指定的Unit也要启动，那么必须在当前Unit之前启动

Conflicts：这里指定的Unit 不能与当前Unit同时运行

Condition...：当前Unit运行必须满足的条件，否则不会运行

Assert...：当前Unit运行必须满足的条件，否则会报启动失败

2.2Service区块

[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：指定环境变量

2.3Install区块

[Install]通常是配置文件的最后一个区块，用来定义如何启动，以及是否开机启动。它的主要字段如下:

WantedBy：它的值是一个或多个Target，当前Unit激活时（enable）符号链接会放入/etc/systemd/system目录下面以Target名+.wants后缀构成的子目录中

RequiredBy：它的值是一个或多个Target，当前Unit激活时，符号链接会放入/etc/systemd/system目录下面以Target 名 + .required后缀构成的子目录中

Alias：当前Unit 可用于启动的别名

Also：当前Unit激活（enable）时，会被同时激活的其他Unit

3. 服务监控启动

3.1socket 触发的服务

涉及网络的服务，可以通过 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.1Restart=on-failure：智能重启

当服务单元文件中设置了Restart=on-failure时，Systemd会在服务因错误退出时尝试重启服务。"错误退出"通常是指服务以非零状态码结束运行，这可能是由于程序崩溃、遇到未处理的异常或其他非正常情况导致的。例如，如果你的服务由于内存不足而崩溃，on-failure将确保服务尝试重新启动。但如果服务是由于正常的系统维护任务而被停止，或者开发人员故意停止服务进行调试，那么它将不会被重启。

其应用场景如下：

生产环境：在不希望因为维护或更新操作而自动重启服务的生产环境中使用。

故障排除：当服务可能需要在出现问题时停止，以便进行故障排除时。

有条件的重启：当你只想在服务因特定问题而停止时重启。

4.2Restart=always：无条件重启

与on-failure相对的是Restart=always选项。不管服务是如何终止的，系统都会尝试将其重启。这意味着即使服务被管理员有意关闭，或者服务正常结束，Systemd也会立即尝试将其重启。

这种策略适用于那些必须始终运行的服务，无论它们是因为何种原因停止的。这确保了即使在进行系统更新或维护时，服务也能尽可能快地恢复运行。

其应用场景如下：

关键服务：对于那些系统的核心功能，如数据库服务或Web服务器，这些服务的任何停机时间都是不可接受的。

高可用性要求：在需要最大程度减少服务停机时间的环境中。

简化管理：在希望无论服务如何停止都能立即重启的情况下。