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服务的配置文件：
代码语言：javascript复制# /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.1 Unit区块
[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.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：指定环境变量
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
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
代码语言：javascript复制[Unit]
Description=Hello World Socket
[Socket]
ListenStream=0.0.0.0:1234
hello-world-socket.service
代码语言：javascript复制[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 ，所以要写完整的单元名：
代码语言：javascript复制systemctl start hello-world-socket.socket3.2 定时器触发的服务
对于定时器触发的服务首先要配置一个 .timer 单元文件，例如：
hello-world.timer
代码语言：javascript复制[Unit]
Description=The Hello-World Timer
[Timer]
OnCalendar=*-*-* *:*:00
其中，OnCalendar 的配置格式同 crontab ，上例表示每分钟触发。
然后需要一个同名的 .service 单元文件。本文开头编译的 hello-world.exe 正好 可作为该定时器启动的程序，例如：
hello-world.service
代码语言：javascript复制[Unit]
Description=The Hello-World Timer
[Service]
Type=oneshot
ExecStart=/absolute/path/to/hello-world.exe
StandardOutput=file:/absolute/path/to/stdout-file
然后启动定时器，并查看状态：
代码语言：javascript复制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服务器，这些服务的任何停机时间都是不可接受的。
高可用性要求：在需要最大程度减少服务停机时间的环境中。
简化管理：在希望无论服务如何停止都能立即重启的情况下。
