Type=¶设置进程的启动类型。必须设为 simple,

exec, forking, oneshot, dbus,

notify, idle 之一：

如果设为 simple (当设置了 ExecStart= 、

但是没有设置 Type= 与 BusName= 时，这是默认值)，

那么 ExecStart= 进程就是该服务的主进程，

并且 systemd 会认为在创建了该服务的主服务进程之后，该服务就已经启动完成。

如果此进程需要为系统中的其他进程提供服务，

那么必须在该服务启动之前先建立好通信渠道(例如套接字)，

这样，在创建主服务进程之后、执行主服务进程之前，即可启动后继单元，

从而加快了后继单元的启动速度。

这就意味着对于 simple 类型的服务来说，

即使不能成功调用主服务进程(例如 User= 不存在、或者二进制可执行文件不存在)，

systemctl start 也仍然会执行成功。

exec 与 simple 类似，不同之处在于，

只有在该服务的主服务进程执行完成之后，systemd 才会认为该服务启动完成。

其他后继单元必须一直阻塞到这个时间点之后才能继续启动。换句话说，

simple 表示当 fork() 函数返回时，即算是启动完成，而

exec 则表示仅在 fork() 与

execve() 函数都执行成功时，才算是启动完成。

这就意味着对于 exec 类型的服务来说，

如果不能成功调用主服务进程(例如 User= 不存在、或者二进制可执行文件不存在)，

那么 systemctl start 将会执行失败。

如果设为 forking ，那么表示

ExecStart= 进程将会在启动过程中使用 fork() 系统调用。

也就是当所有通信渠道都已建好、启动亦已成功之后，父进程将会退出，而子进程将作为主服务进程继续运行。

这是传统UNIX守护进程的经典做法。

在这种情况下，systemd 会认为在父进程退出之后，该服务就已经启动完成。

如果使用了此种类型，那么建议同时设置 PIDFile= 选项，以帮助 systemd 准确可靠的定位该服务的主进程。

systemd 将会在父进程退出之后

立即开始启动后继单元。

oneshot 与 simple 类似，不同之处在于，

只有在该服务的主服务进程退出之后，systemd 才会认为该服务启动完成，才会开始启动后继单元。

此种类型的服务通常需要设置 RemainAfterExit= 选项。

当 Type= 与 ExecStart= 都没有设置时，

Type=oneshot 就是默认值。

dbus 与 simple 类似，不同之处在于，

该服务只有获得了

BusName= 指定的 D-Bus 名称之后，systemd 才会认为该服务启动完成，才会开始启动后继单元。

设为此类型相当于隐含的依赖于 dbus.socket 单元。

当设置了 BusName= 时，

此类型就是默认值。

notify 与 exec 类似，不同之处在于，

该服务将会在启动完成之后通过

sd_notify(3)

之类的接口发送一个通知消息。systemd 将会在启动后继单元之前，

首先确保该进程已经成功的发送了这个消息。如果设为此类型，那么下文的 NotifyAccess=

将只能设为非 none 值。如果未设置

NotifyAccess= 选项、或者已经被明确设为 none ，那么将会被自动强制修改为

main 。注意，目前 Type=notify 尚不能与

PrivateNetwork=yes 一起使用。

idle 与 simple 类似，不同之处在于，

服务进程将会被延迟到所有活动任务都完成之后再执行。

这样可以避免控制台上的状态信息与shell脚本的输出混杂在一起。

注意：(1)仅可用于改善控制台输出，切勿将其用于不同单元之间的排序工具；

(2)延迟最多不超过5秒，

超时后将无条件的启动服务进程。

建议对长时间持续运行的服务尽可能使用

Type=simple (这是最简单和速度最快的选择)。

注意，因为 simple 类型的服务

无法报告启动失败、也无法在服务完成初始化后对其他单元进行排序，

所以，当客户端需要通过仅由该服务本身创建的IPC通道(而非由 systemd 创建的套接字或 D-bus 之类)连接到该服务的时候，

simple 类型并不是最佳选择。在这种情况下，

notify 或 dbus(该服务必须提供 D-Bus 接口) 才是最佳选择，

因为这两种类型都允许服务进程精确的安排

何时算是服务启动成功、何时可以继续启动后继单元。

notify 类型需要服务进程明确使用

sd_notify() 函数或类似的API，

否则，可以使用 forking 作为替代(它支持传统的UNIX服务启动协议)。

最后，如果能够确保服务进程调用成功、服务进程自身不做或只做很少的初始化工作(且不大可能初始化失败)，

那么 exec 将是最佳选择。

注意，因为使用任何

simple 之外的类型都需要等待服务完成初始化，所以可能会减慢系统启动速度。

因此，应该尽可能避免使用

simple 之外的类型(除非必须)。另外，也不建议对长时间持续运行的服务使用 idle 或

oneshot 类型。RemainAfterExit=¶当该服务的所有进程全部退出之后，

是否依然将此服务视为活动(active)状态。

默认值为 noGuessMainPID=¶在无法明确定位

该服务主进程的情况下，

systemd 是否应该猜测主进程的PID(可能不正确)。

该选项仅在设置了

Type=forking

但未设置

PIDFile=

的情况下有意义。

如果PID猜测错误，

那么该服务的失败检测与自动重启功能将失效。

默认值为 yesPIDFile=¶该服务PID文件的路径(一般位于 /run/ 目录下)。

强烈建议在 Type=forking 的情况下明确设置此选项。

如果设为相对路径，那么表示相对于 /run/ 目录。

systemd 将会在此服务启动完成之后，从此文件中读取主服务进程的PID 。

systemd 不会写入此文件，但会在此服务停止后删除它(若仍然存在)。

PID文件的拥有者不必是特权用户，

但是如果拥有者是非特权用户，那么必须施加如下安全限制：

(1)不能是一个指向其他拥有者文件的软连接(无论直接还是间接)；

(2)其中的PID必须指向一个属于该服务的进程。BusName=¶设置与此服务通信

所使用的 D-Bus 名称。

在 Type=dbus 的情况下

必须明确设置此选项。ExecStart=¶在启动该服务时需要执行的

命令行(命令+参数)。

有关命令行的更多细节，

可参见后文的"命令行"小节。

除非 Type=oneshot ，否则必须且只能设置一个命令行。

仅在 Type=oneshot 的情况下，才可以设置任意个命令行(包括零个)，

多个命令行既可以在同一个 ExecStart= 中设置，也可以通过设置多个 ExecStart= 来达到相同的效果。

如果设为一个空字符串，那么先前设置的所有命令行都将被清空。

如果不设置任何 ExecStart= 指令，

那么必须确保设置了 RemainAfterExit=yes 指令，并且至少设置一个 ExecStop= 指令。

同时缺少 ExecStart= 与

ExecStop= 的服务单元是非法的(也就是必须至少明确设置其中之一)。

命令行必须以一个可执行文件(要么是绝对路径、要么是不含任何斜线的文件名)开始，

并且其后的那些参数将依次作为"argv[1] argv[2] …"传递给被执行的进程。

可选的，可以在绝对路径前面加上各种不同的前缀表示不同的含义：

表 1. 可执行文件前的特殊前缀

前缀效果"@"如果在绝对路径前加上可选的 "@" 前缀，那么其后的那些参数将依次作为"argv[0] argv[1] argv[2] …"传递给被执行的进程(注意，argv[0] 是可执行文件本身)。

"-"如果在绝对路径前加上可选的 "-" 前缀，那么即使该进程以失败状态(例如非零的返回值或者出现异常)退出，也会被视为成功退出，但同时会留下错误日志。

"+"如果在绝对路径前加上可选的 "+" 前缀，那么进程将拥有完全的权限(超级用户的特权)，并且 User=, Group=, CapabilityBoundingSet= 选项所设置的权限限制以及 PrivateDevices=, PrivateTmp= 等文件系统名字空间的配置将被该命令行启动的进程忽略(但仍然对其他 ExecStart=, ExecStop= 有效)。

"!"与 "+" 类似(进程仍然拥有超级用户的身份)，不同之处在于仅忽略 User=, Group=, SupplementaryGroups= 选项的设置，而例如名字空间之类的其他限制依然有效。注意，当与 DynamicUser= 一起使用时，将会在执行该命令之前先动态分配一对 user/group ，然后将身份凭证的切换操作留给进程自己去执行。

"!!"与 "!" 极其相似，仅用于让利用 ambient capability 限制进程权限的单元兼容不支持 ambient capability 的系统(也就是不支持 AmbientCapabilities= 选项)。如果在不支持 ambient capability 的系统上使用此前缀，那么 SystemCallFilter= 与 CapabilityBoundingSet= 将被隐含的自动修改为允许进程自己丢弃 capability 与特权用户的身份(即使原来被配置为禁止这么做)，并且 AmbientCapabilities= 选项将会被忽略。此前缀在支持 ambient capability 的系统上完全没有任何效果。

"@", "-" 以及

"+"/"!"/"!!" 之一，可以按任意顺序同时混合使用。

注意，对于 "+", "!", "!!" 前缀来说，仅能单独使用三者之一，不可混合使用多个。

注意，这些前缀同样也可以用于

ExecStartPre=, ExecStartPost=, ExecReload=,

ExecStop=, ExecStopPost= 这些接受命令行的选项。

如果设置了多个命令行，

那么这些命令行将以其在单元文件中出现的顺序依次执行。

如果某个无 "-" 前缀的命令行执行失败，

那么剩余的命令行将不会被继续执行，

同时该单元将变为失败(failed)状态。

当未设置 Type=forking 时，

这里设置的命令行所启动的进程

将被视为该服务的主守护进程。ExecStartPre=,ExecStartPost=¶设置在执行

ExecStart= 之前/后执行的命令行。

语法规则与 ExecStart= 完全相同。

如果设置了多个命令行，

那么这些命令行将以其在单元文件中出现的顺序

依次执行。

如果某个无 "-" 前缀的命令行执行失败，

那么剩余的命令行将不会被继续执行，

同时该单元将变为失败(failed)状态。

仅在所有无 "-" 前缀的

ExecStartPre= 命令全部执行成功的前提下，

才会继续执行 ExecStart= 命令。

ExecStartPost= 命令仅在 ExecStart= 中的命令已经全部执行成功之后才会运行，

判断的标准基于 Type= 选项。

具体说来，对于 Type=simple 或 Type=idle 就是主进程已经成功启动；

对于 Type=oneshot 来说就是最后一个 ExecStart= 进程已经成功退出；

对于 Type=forking 来说就是初始进程已经成功退出；

对于 Type=notify 来说就是已经发送了 "READY=1" ；

对于 Type=dbus 来说就是已经取得了 BusName= 中设置的总线名称。

注意，不可将 ExecStartPre= 用于

需要长时间执行的进程。

因为所有由 ExecStartPre= 派生的子进程

都会在启动 ExecStart= 服务进程之前被杀死。

注意，如果在服务启动完成之前，任意一个 ExecStartPre=,

ExecStart=, ExecStartPost=

中无 "-" 前缀的命令执行失败或超时，

那么，ExecStopPost= 将会被继续执行，而 ExecStop= 则会被跳过。ExecReload=¶这是一个可选的指令，

用于设置当该服务

被要求重新载入配置时

所执行的命令行。

语法规则与

ExecStart=

完全相同。

另外，还有一个特殊的环境变量

$MAINPID

可用于表示主进程的PID，

例如可以这样使用：/bin/kill -HUP $MAINPID

注意，像上例那样，通过向守护进程发送复位信号，

强制其重新加载配置文件，并不是一个好习惯。

因为这是一个异步操作，

所以不适用于需要按照特定顺序重新加载配置文件的服务。

我们强烈建议将

ExecReload=

设为一个

能够确保重新加载配置文件的操作同步完成的命令行。ExecStop=¶这是一个可选的指令，

用于设置当该服务被要求停止时所执行的命令行。

语法规则与

ExecStart=

完全相同。

执行完此处设置的所有命令行之后，该服务将被视为已经停止，

此时，该服务所有剩余的进程将会根据 KillMode= 的设置被杀死(参见

systemd.kill(5))。

如果未设置此选项，那么当此服务被停止时，

该服务的所有进程都将会根据 KillSignal=

的设置被立即全部杀死。

与 ExecReload= 一样，

也有一个特殊的环境变量

$MAINPID 可用于表示主进程的PID 。

一般来说，不应该仅仅设置一个结束服务的命令而不等待其完成。

因为当此处设置的命令执行完之后，

剩余的进程会被按照 KillMode= 与 KillSignal= 的设置立即杀死，

这可能会导致数据丢失。

因此，这里设置的命令必须是同步操作，而不能是异步操作。

注意，仅在服务确实启动成功的前提下，才会执行 ExecStop= 中设置的命令。

如果服务从未启动或启动失败(例如，任意一个

ExecStart=, ExecStartPre=, ExecStartPost=

中无 "-" 前缀的命令执行失败或超时)，

那么 ExecStop= 将会被跳过。

如果想要无条件的在服务停止后执行特定的动作，那么应该使用 ExecStopPost= 选项。

如果服务启动成功，那么即使主服务进程已经终止(无论是主动退出还是被杀死)，也会继续执行停止操作。

因此停止命令必须正确处理这种场景，如果 systemd 发现在调用停止命令时主服务进程已经终止，那么将会撤销 $MAINPID 变量。

重启服务的动作被实现为"先停止、再启动"。所以在重启期间，将会执行 ExecStop= 与 ExecStopPost= 命令。

推荐将此选项用于那些必须在服务干净退出之前执行的命令(例如还需要继续与主服务进程通信)。当此选项设置的命令被执行的时候，应该假定服务正处于完全正常的运行状态，可以正常的与其通信。

如果想要无条件的在服务停止后"清理尸体"，那么应该使用

ExecStopPost= 选项。ExecStopPost=¶这是一个可选的指令，

用于设置在该服务停止之后所执行的命令行。

语法规则与

ExecStart=

完全相同。

注意，与 ExecStop= 不同，无论服务是否启动成功，

此选项中设置的命令都会在服务停止后被无条件的执行。

应该将此选项用于设置那些无论服务是否启动成功，

都必须在服务停止后无条件执行的清理操作。

此选项设置的命令必须能够正确处理由于服务启动失败而造成的各种残缺不全以及数据不一致的场景。

由于此选项设置的命令在执行时，整个服务的所有进程都已经全部结束，

所以无法与服务进行任何通信。

注意，此处设置的所有命令在被调用之后都可以读取如下环境变量：

$SERVICE_RESULT(服务的最终结果),

$EXIT_CODE(服务主进程的退出码), $EXIT_STATUS(服务主进程的退出状态)。

详见 systemd.exec(5)

手册。RestartSec=¶设置在重启服务(Restart=)前暂停多长时间。

默认值是100毫秒(100ms)。

如果未指定时间单位，那么将视为以秒为单位。

例如设为"20"等价于设为"20s"。TimeoutStartSec=¶设置该服务允许的最大启动时长。

如果守护进程未能在限定的时长内发出"启动完毕"的信号，那么该服务将被视为启动失败，并会被关闭。

如果未指定时间单位，那么将视为以秒为单位。

例如设为"20"等价于设为"20s"。

设为 "infinity" 则表示永不超时。

当 Type=oneshot 时，

默认值为 "infinity" (永不超时)，

否则默认值等于

DefaultTimeoutStartSec=

的值(参见

systemd-system.conf(5) 手册)。

如果一个 Type=notify 服务发送了 "EXTEND_TIMEOUT_USEC=…" 信号，

那么允许的启动时长将会在 TimeoutStartSec= 基础上继续延长指定的时长。

注意，必须在 TimeoutStartSec= 用完之前发出第一个延时信号。当启动时间超出

TimeoutStartSec= 之后，该服务可以在维持始终不超时的前提下，不断重复发送

"EXTEND_TIMEOUT_USEC=…" 信号，

直到完成启动(发送 "READY=1" 信号)。详见

sd_notify(3) 手册。TimeoutStopSec=¶此选项有两个用途：

(1)设置每个 ExecStop= 的超时时长。如果其中之一超时，

那么所有后继的 ExecStop= 都会被取消，并且该服务也会被 SIGTERM 信号强制关闭。

如果该服务没有设置 ExecStop= ，那么该服务将会立即被 SIGTERM 信号强制关闭。

(2)设置该服务自身停止的超时时长。如果超时，那么该服务将会立即被 SIGTERM 信号强制关闭(参见

systemd.kill(5)

手册中的 KillMode= 选项)。

如果未指定时间单位，那么将视为以秒为单位。

例如设为"20"等价于设为"20s"。

设为 "infinity" 则表示永不超时。

默认值等于

DefaultTimeoutStopSec= 的值(参见

systemd-system.conf(5) 手册)。

如果一个 Type=notify 服务发送了 "EXTEND_TIMEOUT_USEC=…" 信号，

那么允许的停止时长将会在 TimeoutStopSec= 基础上继续延长指定的时长。

注意，必须在 TimeoutStopSec= 用完之前发出第一个延时信号。当停止时间超出

TimeoutStopSec= 之后，该服务可以在维持始终不超时的前提下，不断重复发送

"EXTEND_TIMEOUT_USEC=…" 信号，直到完成停止。

详见 sd_notify(3) 手册。TimeoutSec=¶一个同时设置

TimeoutStartSec= 与

TimeoutStopSec= 的快捷方式。RuntimeMaxSec=¶允许服务持续运行的最大时长。

如果服务持续运行超过了此处限制的时长，那么该服务将会被强制终止，同时将该服务变为失败(failed)状态。

注意，此选项对 Type=oneshot 类型的服务无效，因为它们会在启动完成后立即终止。

默认值为 "infinity"

(不限时长)。

如果一个 Type=notify 服务发送了 "EXTEND_TIMEOUT_USEC=…" 信号，

那么允许的运行时长将会在 RuntimeMaxSec= 基础上继续延长指定的时长。

注意，必须在 RuntimeMaxSec= 用完之前发出第一个延时信号。当运行时间超出

RuntimeMaxSec= 之后，该服务可以在维持始终不超时的前提下，不断重复发送

"EXTEND_TIMEOUT_USEC=…" 信号，

直到运行结束(发送 "STOPPING=1" 信号或直接退出)。详见

sd_notify(3) 手册。WatchdogSec=¶设置该服务的看门狗(watchdog)的超时时长。

看门狗将在服务成功启动之后被启动。

该服务在运行过程中必须周期性的以 "WATCHDOG=1" ("keep-alive ping")调用

sd_notify(3)

函数。

如果在两次调用之间的时间间隔大于这里设定的值，

那么该服务将被视为失败(failed)状态，

并会被强制使用 WatchdogSignal= 信号(默认为

SIGABRT)关闭。

通过将

Restart= 设为 on-failure,

on-watchdog, on-abnormal,

always 之一，

可以实现在失败状态下的自动重启该服务。

这里设置的值将会通过

WATCHDOG_USEC= 环境变量传递给守护进程，

这样就允许那些支持看门狗的服务自动启用"keep-alive ping"。

如果设置了此选项，

那么 NotifyAccess= 将只能设为非 none 值。

如果 NotifyAccess= 未设置，或者已经被明确设为 none ，

那么将会被自动强制修改为 main 。

如果未指定时间单位，那么将视为以秒为单位。

例如设为"20"等价于设为"20s"。

默认值"0"表示禁用看门狗功能。

详见

sd_watchdog_enabled(3)

与

sd_event_set_watchdog(3)

手册。Restart=¶当服务进程

正常退出、异常退出、被杀死、超时的时候，

是否重新启动该服务。

所谓"服务进程"

是指 ExecStartPre=,

ExecStartPost=,

ExecStop=,

ExecStopPost=,

ExecReload= 中设置的进程。

当进程是由于 systemd 的正常操作(例如 systemctl stop|restart)而被停止时，

该服务不会被重新启动。

所谓"超时"可以是看门狗的"keep-alive ping"超时，

也可以是 systemctl start|reload|stop 操作超时。

该选项的值可以取

no,

on-success,

on-failure,

on-abnormal,

on-watchdog,

on-abort,

always 之一。

no(默认值) 表示不会被重启。

always 表示会被无条件的重启。

on-success 表示仅在服务进程正常退出时重启，

所谓"正常退出"是指：退出码为"0"，

或者进程收到

SIGHUP,

SIGINT,

SIGTERM,

SIGPIPE 信号之一，

并且

退出码符合

SuccessExitStatus=

的设置。

on-failure

表示

仅在服务进程异常退出时重启，

所谓"异常退出"

是指：

退出码不为"0"，

或者

进程被强制杀死(包括

"core dump"以及收到

SIGHUP, SIGINT,

SIGTERM, SIGPIPE

之外的其他信号)，

或者进程由于

看门狗超时

或者 systemd 的操作超时

而被杀死。

表 2. Restart= 的设置分别对应于哪些退出原因

退出原因(↓) | Restart= (→)noalwayson-successon-failureon-abnormalon-aborton-watchdog正常退出XX

退出码不为"0"XX

进程被强制杀死XXXX

systemd 操作超时XXX

看门狗超时XXXX

注意如下例外情况(详见下文)：

(1) RestartPreventExitStatus=

中列出的退出码或信号永远不会导致该服务被重启。

(2) 被 systemctl stop 命令或等价的操作停止的服务永远不会被重启。

(3) RestartForceExitStatus=

中列出的退出码或信号将会

无条件的导致该服务被重启。

注意，服务的重启频率仍然会受到由

StartLimitIntervalSec=

与 StartLimitBurst= 定义的启动频率的制约。详见

systemd.unit(5)

手册。只有在达到启动频率限制之后，

重新启动的服务才会进入失败状态。

对于需要长期持续运行的守护进程，

推荐设为

on-failure 以增强可用性。

对于自身可以自主选择何时退出的服务，

推荐设为

on-abnormalSuccessExitStatus=¶额外定义其他的进程"正常退出"状态。

也就是，在退出码"0"、以及表示"正常退出"的 SIGHUP,

SIGINT, SIGTERM,

SIGPIPE 信号之外，

再额外添加一组表示"正常退出"的退出码或信号。

可以设为一系列

以空格分隔的数字退出码或者信号名称，

例如：SuccessExitStatus=1 2 8 SIGKILL

表示当进程的退出码是 1, 2, 8

或被 SIGKILL 信号终止时，

都可以视为"正常退出"。

如果多次使用此选项，

那么最终的结果将是多个列表的合并。

如果将此选项设为空，

那么先前设置的列表

将被清空。RestartPreventExitStatus=¶可以设为一系列

以空格分隔的数字退出码或信号名称，

当进程的退出码或收到的信号与此处的设置匹配时，

无论 Restart= 选项

是如何设置的，

该服务都将无条件的

禁止重新启动。

例如：RestartPreventExitStatus=1 6 SIGABRT

可以确保退出码 1, 6 与 SIGABRT 信号

不会导致该服务被自动重启。

默认值为空，

表示完全遵守

Restart= 的设置。

如果多次使用此选项，那么最终的结果将是多个列表的合并。

如果将此选项设为空，那么先前设置的列表将被清空。RestartForceExitStatus=¶可以设为一系列以空格分隔的数字退出码或信号名称，

当进程的退出码或收到的信号与此处的设置匹配时，

无论 Restart= 是如何设置的，该服务都将无条件的被自动重新启动。

默认值为空，表示完全遵守 Restart= 的设置。

如果多次使用此选项，那么最终的结果将是多个列表的合并。

如果将此选项设为空，那么先前设置的列表将被清空。RootDirectoryStartOnly=¶接受一个布尔值。

设为 yes 表示根目录

RootDirectory= 选项(参见

systemd.exec(5)

手册)

仅对 ExecStart= 中的程序有效，

而对 ExecStartPre=,

ExecStartPost=,

ExecReload=, ExecStop=,

ExecStopPost= 中的程序无效。

默认值 no 表示根目录对所有 Exec*=

系列选项中的程序都有效。NonBlocking=¶是否为所有基于套接字启动传递的文件描述符设置非阻塞标记(O_NONBLOCK)。

设为 yes 表示除了通过 FileDescriptorStoreMax= 引入的文件描述符之外，

所有 ≥3 的文件描述符(非 stdin, stdout, stderr 文件描述符)都将被设为非阻塞模式。

该选项仅在与 socket 单元

(systemd.socket(5))

联用的时候才有意义。

对于那些先前已经通过 FileDescriptorStoreMax= 引入的文件描述符则毫无影响。

默认值为 noNotifyAccess=¶设置通过

sd_notify(3)

访问服务状态通知套接字的模式。

可以设为 none(默认值), main, exec, all 之一。

none 表示不更新任何守护进程的状态，忽略所有状态更新消息。

main 表示仅接受主进程的状态更新消息。

exec 表示仅接受主进程以及 Exec*= 进程的状态更新消息。

all 表示接受该服务cgroup内所有进程的状态更新消息。

当设置了 Type=notify 或 WatchdogSec= 的时候(见前文)，此选项将只能设为非 none 值。

如果 NotifyAccess= 未设置，或者已经被明确设为 none ，

那么将会被自动强制修改为 main 。

注意，服务单元的 sd_notify() 通知能够正常工作的前提，

是必须满足如下两个条件之一：

(1)在 PID=1 的进程处理通知消息时，发送该通知的进程依然在运行；

(2)发送该通知的进程是 systemd 派生的子进程(也就是匹配 main 或 exec 的进程)。

如果服务单元中的某个辅助进程在发送了 sd_notify() 通知之后就立即退出了，

那么 systemd 将有可能来不及将该通知关联到这个服务单元上。

在这种情况下，即使明确设置了 NotifyAccess=all ，

该通知也可能会被忽略掉。Sockets=¶设置一个

socket 单元的名称，

表示该服务在启动时应当从它继承套接字文件描述符。

通常并不需要明确设置此选项，

因为所有与该服务同名(不算后缀)的 socket 单元的套接字文件描述符，

都会被自动的

传递给派生进程。

注意：

(1)同一个套接字文件描述符可以被传递给多个不同的进程(服务)。

(2)当套接字上有流量进入时，

被启动的可能是另一个不同于该服务的其他服务。

换句话说就是：

套接字单元中的 Sockets=

所指向的服务单元中的

Sockets=

未必要反向指回去。

如果多次使用此选项，

那么最终的结果将是多个socket单元的合集。

如果将此选项设为空，

那么先前设置的所有socket单元

都将被清空。FileDescriptorStoreMax=¶允许在 systemd 中最多为该服务存储多少个使用

"FDSTORE=1" 消息(sd_pid_notify_with_fds(3))

的文件描述符。默认值为"0"(不存储)。

通过将服务重启过程中不应该关闭的套接字与文件描述符使用这种方法保存起来，

就可以实现让服务在重启(正常重启或崩溃重启)之后不丢失其状态。

进程的状态可以被序列化为一个文件之后保存在 /run 中，

或者保存在一个 memfd_create(2) 内存文件描述符中(这是更好的选择)。

所有被 systemd 暂存的文件描述符都将在该服务重启之后交还给该服务的主进程。

所有被 systemd 暂存的文件描述符都将在遇到如下两种情况时被自动关闭：

(1)收到 POLLHUP 或 POLLERR 信号；

(2)该服务被彻底停止，并且没有任何剩余的任务需要处理。

如果使用了此选项，那么前文的 NotifyAccess=

应该被设为允许访问 systemd 提供的通知套接字。若未设置

NotifyAccess= ，那么将被隐含的设为

mainUSBFunctionDescriptors=¶设为一个包含

USB

FunctionFS 描述符的文件路径，

以实现 USB gadget 支持。

仅与配置了 ListenUSBFunction=

的 socket 单元一起使用。该文件的内容将被写入

ep0

文件。USBFunctionStrings=¶设为一个包含

USB FunctionFS 字符串的文件路径。

其行为与上面的 USBFunctionDescriptors=

类似。