systemd.unit 中文手册

有利于人类阅读的、对单元进行简单描述的字符串。将被 systemd 或其他程序用来标记此单元， 这个字符串应该只用于识别此单元即可，不需要过分说明。例如 "Apache2 Web Server" 就是一个好例子，而 "high-performance light-weight HTTP server" (太通用) 与 "Apache2" (信息太少) 则是两个坏例子。因为 systemd 将会把这个字符串用于状态信息中("Starting description...", "Started description.", "Reached target description.", "Failed to start description.")，所以这个字符串应该表现的像一个名词， 而不是一个完整的句子或带有动词的短语。比如 "exiting the container" 或 "updating the database once per day." 就是典型的坏例子。

一组用空格分隔的文档URI列表， 这些文档是对此单元的详细说明。 可接受 "http://", "https://", "file:", "info:", "man:" 五种URI类型。 有关URI语法的详细说明，参见 uri(7) 手册。 这些URI应该按照相关性由高到低列出。 比如，将解释该单元作用的文档放在第一个， 最好再紧跟单元的配置说明， 最后再附上其他文档。 可以多次使用此选项， 依次向文档列表尾部添加新文档。 但是，如果为此选项设置一个空字符串， 那么表示 清空先前已存在的列表。

设置此单元所必须依赖的其他单元。当启动此单元时，也必须启动这里列出的所有其他单元。 如果此处列出的某个单元启动失败、并且恰好又设置了到这个失败单元的 After= 依赖，那么将不会启动此单元。此外，无论是否设置了到被依赖单元的 After= 依赖，只要某个被依赖的单元被显式停止，那么该单元也会被连带停止。 想要添加多个单元，可以多次使用此选项，也可以设置一个空格分隔的单元列表。 注意，此选项并不影响单元之间的启动或停止顺序。 要想调整单元之间的启动或停止顺序，请使用 After= 或 Before= 选项。 例如，在 foo.service 中设置了 Requires=bar.service ， 但是并未使用 After= 或 Before= 设定两者的启动顺序， 那么，当需要启动 foo.service 的时候，这两个单元会被并行的同时启动。 建议使用 Wants= 代替 Requires= 来设置单元之间的非致命依赖关系， 从而有助于获得更好的健壮性， 特别是在某些单元启动失败的时候。

注意，设置了此依赖并不意味着当本单元处于运行状态时，被依赖的其他单元也必须总是处于运行状态。 例如：(1)失败的条件检查(例如后文的 ConditionPathExists=, ConditionPathIsSymbolicLink=, …)只会导致被依赖的单元跳过启动，而不会导致被依赖的单元启动失败(也就是进入"failed"状态)。 (2)某些被依赖的单元可能会自己主动停止(例如有的服务进程可能会主动干净的退出、有的设备可能被用户拔出)， 而不会导致本单元自身也跟着一起停止。 要想达到这样的效果，可以同时联合使用 BindsTo= 与 After= 依赖，这样就可以确保：在被依赖的其他单元没有处于运行状态时， 本单元自身永远不会启动成功(详见后文)。

注意， 此种依赖关系也可以在单元文件之外通过向 .requires/目录中添加软连接来设置。 详见前文。

与 Requires= 类似。不同之处在于：当此单元启动时，这里列出的依赖单元必须已经全部处于启动成功的状态， 否则，此单元将会立即进入启动失败的状态，并且也不会启动那些尚未成功启动的被依赖单元。 因为 Requisite= 不隐含任何顺序依赖(即使两个单元在同一个事务中启动)， 所以，此选项经常与 After= 一起使用， 以确保此单元不会在启动时间上早于被依赖的单元。

如果 a.service 中包含了 Requisite=b.service ，那么这个依赖关系将在 b.service 的属性列表中显示为 RequisiteOf=a.service 。 也就是说，不能直接设置 RequisiteOf= 依赖。

此选项是 Requires= 的弱化版。 当此单元被启动时， 所有这里列出的其他单元只是尽可能被启动。 但是，即使某些单元不存在或者未能启动成功， 也不会影响此单元的启动。 推荐使用此选项来设置单元之间的依赖关系。

注意， 此种依赖关系也可以在单元文件之外通过向 .wants/ 目录中添加软连接来设置， 详见前文。

与 Requires= 类似，但是依赖性更强： 如果这里列出的任意一个单元停止运行或者崩溃，那么也会连带导致该单元自身被停止。 这就意味着该单元可能因为 这里列出的任意一个单元的 主动退出、某个设备被拔出、某个挂载点被卸载， 而被强行停止。

如果将某个被依赖的单元同时放到 After= 与 BindsTo= 选项中，那么效果将会更加强烈：被依赖的单元必须严格的先于本单元启动成功之后， 本单元才能开始启动。这就意味着，不但在被依赖的单元意外停止时，该单元必须停止， 而且在被依赖的单元由于条件检查失败(例如后文的 ConditionPathExists=, ConditionPathIsSymbolicLink=, …)而被跳过时， 该单元也将无法启动。正因为如此，在很多场景下，需要同时使用 BindsTo= 与 After= 选项。

如果 a.service 中包含了 BindsTo=b.service ，那么这个依赖关系将在 b.service 的属性列表中显示为 BoundBy=a.service 。 也就是说，不能直接设置 BoundBy= 依赖。

与 Requires= 类似， 不同之处在于：仅作用于单元的停止或重启。 其含义是，当停止或重启这里列出的某个单元时， 也会同时停止或重启该单元自身。 注意，这个依赖是单向的， 该单元自身的停止或重启并不影响这里列出的单元。

如果 a.service 中包含了 PartOf=b.service ，那么这个依赖关系将在 b.service 的属性列表中显示为 ConsistsOf=a.service 。 也就是说，不能直接设置 ConsistsOf= 依赖。

指定单元之间的冲突关系。 接受一个空格分隔的单元列表，表明该单元不能与列表中的任何单元共存， 也就是说：(1)当此单元启动的时候，列表中的所有单元都将被停止； (2)当列表中的某个单元启动的时候，该单元同样也将被停止。 注意，此选项与 After= 和 Before= 选项没有任何关系。

如果两个相互冲突的单元A与B 需要在同一个事务内作为B启动， 那么这个事务要么会失败(A与B都是事务中的必要部分[Requires])， 要么就是必须被修改(A与B中至少有一个是事务中的非必要部分)。 在后一种情况下， 将会剔除一个非必要的单元 (若两个都是非必要的单元， 则优先剔除A)。

强制指定单元之间的先后顺序，接受一个空格分隔的单元列表。 假定 foo.service 单元包含 Before=bar.service 设置， 那么当两个单元都需要启动的时候， bar.service 将会一直延迟到 foo.service 启动完毕之后再启动。 注意，停止顺序与启动顺序正好相反，也就是说， 只有当 bar.service 完全停止后，才会停止 foo.service 单元。 After= 的含义与 Before= 正好相反。 假定 foo.service 单元包含 After=bar.service 设置， 那么当两个单元都需要启动的时候， foo.service 将会一直延迟到 bar.service 启动完毕之后再启动。 注意，停止顺序与启动顺序正好相反，也就是说， 只有当 foo.service 完全停止后，才会停止 bar.service 单元。 注意，此二选项仅用于指定先后顺序， 而与 Requires=, Wants=, BindsTo= 这些选项没有任何关系。 不过在实践中也经常遇见将某个单元同时设置到 After= 与 Requires= 选项中的情形。 可以多次使用此二选项，以将多个单元添加到列表中。 假定两个单元之间存在先后顺序(无论谁先谁后)，并且一个要停止而另一个要启动，那么永远是"先停止后启动"的顺序。 但如果两个单元之间没有先后顺序，那么它们的停止和启动就都是相互独立的，并且是并行的。 对于不同类型的单元来说，判断启动是否已经完成的标准并不完全相同。 特别的，对于设置在 Before=/After= 中的服务单元来说， 只有在服务单元内配置的所有启动命令全部都已经被调用，并且对于每一个被调用的命令， 要么确认已经调用失败、要么确认已经成功运行的情况下， 才能认为已经完成启动。

接受一个空格分隔的单元列表。 当该单元进入失败("failed")状态时， 将会启动列表中的单元。使用了 Restart= 的服务单元仅在超出启动频率限制之后， 才会进入失败(failed)状态。

接受一个空格分隔的单元列表。 PropagatesReloadTo= 表示 在 reload 该单元时， 也同时 reload 所有列表中的单元。 ReloadPropagatedFrom= 表示 在 reload 列表中的某个单元时， 也同时 reload 该单元。

接受一个空格分隔的单元列表， 表示将该单元所启动的进程加入到列表单元的网络及 临时文件(/tmp, /var/tmp)的名字空间中。 此选项仅适用于支持 PrivateNetwork= 与/或 PrivateTmp= 指令的单元(对加入者与被加入者都适用)。详见 systemd.exec(5) 手册。 如果单元列表中 仅有一个单元处于已启动状态， 那么该单元将加入到 这个唯一已启动单元的名字空间中。 如果单元列表中 有多个单元处于已启动状态， 那么该单元将 随机加入一个已启动单元的 名字空间中。

接受一个空格分隔的绝对路径列表，表示该单元将会使用到这些文件系统路径。 所有这些路径中涉及的挂载点所对应的 mount 单元，都会被隐式的添加到 Requires= 与 After= 选项中。 也就是说，这些路径中所涉及的挂载点都会在启动该单元之前被自动挂载。

注意，虽然带有 noauto 标记的挂载点不会被 local-fs.target 自动挂载， 但是它并不影响此选项所设置的依赖关系。 也就是说，带有 noauto 标记的挂载点 依然会在启动该单元之前被自动挂载。

可设为 "fail", "replace", "replace-irreversibly", "isolate", "flush", "ignore-dependencies", "ignore-requirements" 之一。 默认值是 "replace" 。 指定 OnFailure= 中列出的单元应该以何种方式排队。值的含义参见 systemctl(1) 手册中对 --job-mode= 选项的说明。 如果设为 "isolate" ， 那么只能在 OnFailure= 中设置一个单独的单元。

接受一个布尔值。设为 yes 表示在执行 systemctl isolate ... 命令时，此单元不会被停止。 对于 service, target, socket, timer, path 单元来说，默认值是 false ； 对于 slice, scope, device, swap, mount, automount 单元来说， 默认值是 true 。

如果设为 yes ， 那么当此单元不再被任何已启动的单元依赖时， 将会被自动停止。 默认值 no 的含义是， 除非此单元与其他即将启动的单元冲突， 否则即使此单元已不再被任何已启动的单元依赖， 也不会自动停止它。

如果设为 yes ， 那么此单元将拒绝被手动启动(RefuseManualStart=) 或拒绝被手动停止(RefuseManualStop=)。 也就是说， 此单元只能作为其他单元的依赖条件而存在， 只能因为依赖关系而被间接启动或者间接停止， 不能由用户以手动方式直接启动或者直接停止。 设置此选项是为了 禁止用户意外的启动或者停止某些特定的单元。 默认值是 no

如果设为 yes ， 那么此单元将允许被 systemctl isolate 命令操作， 否则将会被拒绝。 唯一一个将此选项设为 yes 的理由，大概是为了兼容SysV初始化系统。 此时应该仅考虑对 target 单元进行设置， 以防止系统进入不可用状态。 建议保持默认值 no

默认值 yes 表示为此单元隐式地创建默认依赖。 不同类型的单元，其默认依赖也不同，详见各自的手册页。 例如对于 service 单元来说， 默认的依赖关系是指： (1)开机时，必须在基础系统初始化完成之后才能启动该服务； (2)关机时，必须在该服务完全停止后才能关闭基础系统。 通常，只有那些在系统启动的早期就必须启动的单元， 以及那些必须在系统关闭的末尾才能关闭的单元， 才可以将此选项设为 no 。 注意，设为 no 并不表示取消所有的默认依赖， 只是表示取消非关键的默认依赖。 强烈建议对绝大多数普通单元 保持此选项的默认值 yes 。

设置此单元的"垃圾回收"策略。可设为 inactive(默认值) 或 inactive-or-failed 之一。默认值 inactive 表示如果该单元处于停止(inactive)状态，并且没有被其他客户端、任务、单元所引用，那么该单元将会被卸载。 注意，如果此单元处于失败(failed)状态，那么是不会被卸载的， 它会一直保持未卸载状态，直到用户调用 systemctl reset-failed (或类似的命令)重置了 failed 状态。设为 inactive-or-failed 表示无论此单元处于停止(inactive)状态还是失败(failed)状态， 都将被卸载(无需重置 failed 状态)。 注意，在这种"垃圾回收"策略下， 此单元的所有结果(退出码、退出信号、资源消耗 …) 都会在此单元结束之后立即清除(只剩下此前已经记录在日志中的痕迹)。

当此单元停止并进入失败(failed)或停止(inactive)状态时，应当执行什么动作。 对于系统单元，可以设为 none, reboot, reboot-force, reboot-immediate, poweroff, poweroff-force, poweroff-immediate, exit, exit-force 之一。 对于用户单元，仅可设为 none, exit, exit-force 之一。两个选项的默认值都是 none

默认值 none 表示 不触发任何动作。 reboot/poweroff 表示按照常规关机流程重启/关闭整个系统(等价于 systemctl reboot|poweroff)。 reboot-force/poweroff-force 表示强制杀死所有进程之后强制重启/关机， 虽然可能会造成应用程序数据丢失，但是不会造成文件系统不一致(等价于 systemctl reboot|poweroff -f)。 reboot-immediate/poweroff-immediate 表示强制立即执行 reboot(2) 系统调用重启/关机， 可能会造成数据丢失以及文件系统不一致(等价于 systemctl reboot|poweroff -ff)。 exit 表示按照常规关闭流程，按部就班的退出 systemd 系统管理器。 exit-force 表示立即强制退出 systemd 系统管理器(不再按部就班的逐一退出全部服务)。 当设为 exit 或 exit-force 时， systemd 系统管理器将会默认把此单元主进程的返回值(如果有)用作系统管理器自身的返回值。 当然，这个默认行为可以通过下面的 FailureActionExitStatus=/SuccessActionExitStatus= 进行修改。

当 FailureAction=/SuccessAction= 的值为 exit 或 exit-force 之一，并且设定的动作被触发时，应该返回什么样退出码给容器管理器(对于系统服务) 或 systemd 系统管理器(对于用户服务)。 默认情况下，将会使用该单元主进程的退出码(如果有)。 取值范围是 0…255 之间的一个整数。 设为空字符串表示重置回默认行为。

当该单元的一个任务(job)进入队列的时候， JobTimeoutSec= 用于设置从该任务进入队列开始计时、到该任务最终完成，最多可以使用多长时间， JobRunningTimeoutSec= 用于设置从该任务实际运行开始计时、到该任务最终完成，最多可以使用多长时间。 如果上述任意一个设置超时，那么超时的任务将被撤销，并且该单元将保持其现有状态不变(而不是进入 "failed" 状态)。 对于非 device 单元来说，DefaultTimeoutStartSec= 选项的默认值是 "infinity"(永不超时)， 而 JobRunningTimeoutSec= 的默认值等于 DefaultTimeoutStartSec= 的值。 注意，此处设置的超时不是指单元自身的超时(例如 TimeoutStartSec= 就是指单元自身的超时)， 而是指该单元在启动或者停止等状态变化过程中，等候某个外部任务完成的最长时限。 换句话说，适用于单元自身的超时设置(例如 TimeoutStartSec=)用于指定单元自身在改变其状态时，总共允许使用多长时间； 而此处设置的超时则是设置此单元在改变其状态的过程中，等候某个外部任务完成所能容忍的最长时间。

JobTimeoutAction= 用于指定当超时发生时(参见上文的 JobTimeoutSec= 与 JobRunningTimeoutSec= 选项)，将触发什么样的额外动作。 可接受的值与 StartLimitAction= 相同，默认值为 none 。 JobTimeoutRebootArgument= 用于指定传递给 reboot(2) 系统调用的字符串参数。

设置单元的启动频率限制。 也就是该单元在 interval 时间内最多允许启动 burst 次。 StartLimitIntervalSec= 用于设置时长(默认值等于 systemd 配置文件(system.conf)中 DefaultStartLimitIntervalSec= 的值)，设为 0 表示没有限制。 StartLimitBurst= 用于设置在给定的时长内，最多允许启动多少次(默认值等于 systemd 配置文件(system.conf)中 DefaultStartLimitBurst= 的值)。 虽然此选项通常与 Restart= 选项(参见 systemd.service(5)) 一起使用， 但实际上，此选项作用于任何方式的启动(包括手动启动)，而不仅仅是由 Restart= 触发的启动。 注意，一旦某个设置了 Restart= 自动重启逻辑的单元触碰到了启动频率限制， 那么该单元将再也不会尝试自动重启； 不过，如果该单元在经过 interval 时长之后，又被手动重启成功的话，那么该单元的自动重启逻辑将会被再次激活。 注意，systemctl reset-failed 命令能够重置单元的启动频率计数器。 系统管理员在手动启动某个已经触碰到了启动频率限制的单元之前，可以使用这个命令清除启动限制。 注意，因为启动频率限制位于所有单元条件检查之后， 所以基于失败条件的启动不会计入启动频率限制的启动次数之中。 注意，这些选项对 slice, target, device, scope 单元没有意义， 因为这几种单元要么永远不会启动失败、要么只能成功启动一次。

当一个单元因为垃圾回收(见前文)而被卸载的时候， 该单元的启动频率计数器也会被一起清除。 这就意味着对不被持续引用的单元设置启动频率限制是无效的。

设置该单元在触碰了 StartLimitIntervalSec= 与 StartLimitBurst= 定义的启动频率限制时，将会执行什么动作。 可接受的值与 FailureAction=/SuccessAction= 相同，值的含义也相同。 默认值 none 表示除了禁止启动之外， 不触发任何其他动作。

当 StartLimitAction= 或 FailureAction= 触发重启动作时， 此选项的值就是传递给 reboot(2) 系统调用的字符串参数。 相当于 systemctl reboot 命令接收的可选参数。

这组选项用于在启动单元之前，首先测试特定的条件是否为真。 若为假，则悄无声息地跳过此单元的启动(仅是跳过，而不是进入"failed"状态)。 注意，即使某单元由于测试条件为假而被跳过， 那些由于依赖关系而必须先于此单元启动的单元并不会受到影响(也就是会照常启动)。 可以使用条件表达式来跳过那些对于本机系统无用的单元， 比如那些对于本机内核或运行环境没有用处的功能。 如果想要单元在测试条件为假时， 除了跳过启动之外，还要在日志中留下痕迹(而不是悄无声息的跳过)， 可以使用对应的另一组 AssertArchitecture=, AssertVirtualization=, … 选项(见后文)。

ConditionArchitecture= 检测是否运行于 特定的硬件平台： x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, ia64, parisc, parisc64, s390, s390x, sparc, sparc64, mips, mips-le, mips64, mips64-le, alpha, arm, arm-be, arm64, arm64-be, sh, sh64, m68k, tilegx, cris, arc, arc-be, native(编译 systemd 时的目标平台)。 可以在这些关键字前面加上感叹号(!)前缀 表示逻辑反转。注意， Personality= 的值 对此选项 没有任何影响。

ConditionVirtualization= 检测是否运行于(特定的)虚拟环境中： yes(某种虚拟环境), no(物理机), vm(某种虚拟机), container(某种容器), qemu, kvm, zvm, vmware, microsoft, oracle, xen, bochs, uml, bhyve, qnx, openvz, lxc, lxc-libvirt, systemd-nspawn, docker, rkt, private-users(用户名字空间)。参见 systemd-detect-virt(1) 手册以了解所有已知的虚拟化技术及其标识符。 如果嵌套在多个虚拟化环境内， 那么以最内层的那个为准。 可以在这些关键字前面加上感叹号(!)前缀表示逻辑反转。

ConditionHost= 检测系统的 hostname 或者 "machine ID" 。 参数可以是：(1)一个主机名字符串(可以使用 shell 风格的通配符)， 该字符串将会与 本机的主机名(也就是 gethostname(2) 的返回值)进行匹配；(2)或者是一个 "machine ID" 格式的字符串(参见 machine-id(5) 手册)。 可以在字符串前面加上感叹号(!)前缀表示逻辑反转。

ConditionKernelCommandLine= 检测是否设置了某个特定的内核引导选项。 参数可以是一个单独的单词，也可以是一个 "var=val" 格式的赋值字符串。 如果参数是一个单独的单词，那么以下两种情况都算是检测成功： (1)恰好存在一个完全匹配的单词选项； (2)在某个 "var=val" 格式的内核引导选项中等号前的 "var" 恰好与该单词完全匹配。 如果参数是一个 "var=val" 格式的赋值字符串， 那么必须恰好存在一个完全匹配的 "var=val" 格式的内核引导选项，才算检测成功。 可以在字符串前面加上感叹号(!)前缀表示逻辑反转。

ConditionKernelVersion= 检测内核版本(uname -r) 是否匹配给定的表达式(或在字符串前面加上感叹号(!)前缀表示"不匹配")。 表达式必须是一个单独的字符串。如果表达式以 "<", "<=", "=", ">=", ">" 之一开头， 那么表示对内核版本号进行比较，否则表示按照 shell 风格的通配符表达式进行匹配。

注意，企图根据内核版本来判断内核支持哪些特性是不可靠的。 因为发行版厂商经常将高版本内核的新驱动和新功能移植到当前发行版使用的低版本内核中， 所以，对内核版本的检查是不能在不同发行版之间随意移植的， 不应该用于需要跨发行版部署的单元。

ConditionSecurity= 检测是否启用了 特定的安全技术： selinux, apparmor, tomoyo, ima, smack, audit, uefi-secureboot 。 可以在这些关键字前面加上感叹号(!)前缀表示逻辑反转。

ConditionCapability= 检测 systemd 的 capability 集合中 是否存在 特定的 capabilities(7) 。 参数应设为例如 "CAP_MKNOD" 这样的 capability 名称。 注意，此选项不是检测特定的 capability 是否实际可用，而是仅检测特定的 capability 在绑定集合中是否存在。 可以在名称前面加上感叹号(!)前缀表示逻辑反转。

ConditionACPower= 检测系统是否 正在使用交流电源。 yes 表示至少在使用一个交流电源， 或者更本不存在任何交流电源。 no 表示存在交流电源， 但是 没有使用其中的任何一个。

ConditionNeedsUpdate= 可设为 /var 或 /etc 之一， 用于检测指定的目录是否需要更新。 设为 /var 表示 检测 /usr 目录的最后更新时间(mtime) 是否比 /var/.updated 文件的最后更新时间(mtime)更晚。 设为 /etc 表示 检测 /usr 目录的最后更新时间(mtime) 是否比 /etc/.updated 文件的最后更新时间(mtime)更晚。 可以在值前面加上感叹号(!)前缀表示逻辑反转。 当更新了 /usr 中的资源之后，可以通过使用此选项， 实现在下一次启动时更新 /etc 或 /var 目录的目的。 使用此选项的单元必须设置 ConditionFirstBoot=systemd-update-done.service ， 以确保在 .updated 文件被更新之前启动完毕。 参见 systemd-update-done.service(8) 手册。

ConditionFirstBoot= 可设为 yes 或 no 。 用于检测 /etc 目录是否处于未初始化的原始状态(重点是 /etc/machine-id 文件是否存在)。 此选项可用于系统出厂后(或者恢复出厂设置之后)， 首次开机时执行必要的初始化操作。

ConditionPathExists= 检测 指定的路径 是否存在， 必须使用绝对路径。 可以在路径前面 加上感叹号(!)前缀 表示逻辑反转。

ConditionPathExistsGlob= 与 ConditionPathExists= 类似， 唯一的不同是支持 shell 通配符。

ConditionPathIsDirectory= 检测指定的路径是否存在并且是一个目录，必须使用绝对路径。 可以在路径前面加上感叹号(!)前缀表示逻辑反转。

ConditionPathIsSymbolicLink= 检测指定的路径是否存在并且是一个软连接，必须使用绝对路径。 可以在路径前面加上感叹号(!)前缀 表示逻辑反转。

ConditionPathIsMountPoint= 检测指定的路径是否存在并且是一个挂载点，必须使用绝对路径。 可以在路径前面加上感叹号(!)前缀表示逻辑反转。

ConditionPathIsReadWrite= 检测指定的路径是否存在并且可读写(rw)，必须使用绝对路径。 可以在路径前面加上感叹号(!)前缀 表示逻辑反转。

ConditionDirectoryNotEmpty= 检测指定的路径是否存在并且是一个非空的目录，必须使用绝对路径。 可以在路径前面加上感叹号(!)前缀 表示逻辑反转。

ConditionFileNotEmpty= 检测指定的路径是否存在并且是一个非空的普通文件，必须使用绝对路径。 可以在路径前面加上感叹号(!)前缀 表示逻辑反转。

ConditionFileIsExecutable= 检测指定的路径是否存在并且是一个可执行文件，必须使用绝对路径。 可以在路径前面加上感叹号(!)前缀 表示逻辑反转。

ConditionUser= 检测 systemd 是否以给定的用户身份运行。 参数可以是数字形式的 "UID" 、 或者字符串形式的UNIX用户名、 或者特殊值 "@system"(表示属于系统用户范围内) 。 此选项对于系统服务无效， 因为管理系统服务的 systemd 进程 总是以 root 用户身份运行。

ConditionGroup= 检测 systemd 是否以给定的用户组身份运行。 参数可以是数字形式的 "GID" 或者字符串形式的UNIX组名。 注意：(1)这里所说的"组"可以是"主组"(Primary Group)、"有效组"(Effective Group)、"辅助组"(Auxiliary Group)； (2)此选项不存在特殊值 "@system"

ConditionControlGroupController= 检测给定的一组 cgroup 控制器(例如 cpu)是否全部可用。 通过例如 cgroup_disable=controller 这样的内核命令行可以禁用名为"controller"的 cgroup 控制器。 列表中的多个 cgroup 控制器之间可以使用空格分隔。 不能识别的 cgroup 控制器将被忽略。 能够识别的全部 cgroup 控制器如下： cpu, cpuacct, io, blkio, memory, devices, pids

如果在条件之前加上管道符(|)，那么这个条件就是"触发条件"， 其含义是只要满足一个触发条件，该单元就会被启动； 如果在条件之前没有管道符(|)，那么这个条件就是"普通条件"， 其含义是必须满足全部普通条件，该单元才会被启动。 如果在某个单元文件内， 同时存在"触发条件"与"普通条件"，那么必须满足全部普通条件， 并且至少满足一个触发条件，该单元才会被启动。 如果需要对某个条件同时使用"|"与"!"， 那么"|"必须位于"!"之前。 除 ConditionPathIsSymbolicLink= 之外， 其他路径检测选项都会追踪软连接。 如果将上述某个检测选项设为空字符串， 那么表示重置该选项先前的所有设置， 也就是清空该选项先前的设置。

与前一组 ConditionArchitecture=, ConditionVirtualization=, … 测试选项类似，这一组选项用于在单元启动之前， 首先进行相应的断言检查。不同之处在于，任意一个断言的失败， 都会导致跳过该单元的启动并将失败的断言突出记录在日志中。 注意，断言失败并不导致该单元进入失败("failed")状态(实际上，该单元的状态不会发生任何变化)， 它仅影响该单元的启动任务队列。 如果用户希望清晰的看到某些单元因为未能满足特定的条件而导致没有正常启动， 那么可以使用断言表达式。

注意，无论是前一组条件表达式、还是这一组断言表达式，都不会改变单元的状态。 因为这两组表达式都是在启动任务队列开始执行时进行检查(也就是，位于依赖任务队列之后、该单元自身启动任务队列之前)， 所以，条件表达式和断言表达式 都不适合用于对单元的依赖条件进行检查。

指定 生成此单元时所参考的配置文件。 仅用于单元生成器 标识此单元生成自何处。 普通的单元 不应该使用它。

启用时使用的别名，可以设为一个空格分隔的别名列表。 每个别名的后缀(也就是单元类型)都必须与该单元自身的后缀相同。 如果多次使用此选项，那么每个选项所设置的别名都会被添加到别名列表中。 在启用此单元时，systemctl enable 命令将会为每个别名创建一个指向该单元文件的软连接。 注意，因为 mount, slice, swap, automount 单元不支持别名， 所以不要在这些类型的单元中使用此选项。

接受一个空格分隔的单元列表， 表示在使用 systemctl enable 启用此单元时， 将会在每个列表单元的 .wants/ 或 .requires/ 目录中创建一个指向该单元文件的软连接。 这相当于为每个列表中的单元文件添加了 Wants=此单元 或 Requires=此单元 选项。 这样当列表中的任意一个单元启动时，该单元都会被启动。 有关 Wants= 与 Requires= 的详细说明， 参见前面 [Unit] 小节的说明。 如果多次使用此选项， 那么每个选项的单元列表都会合并在一起。

在普通的 bar.service 单元内设置 WantedBy=foo.service 选项 与设置 Alias=foo.service.wants/bar.service 选项基本上是等价的。 但是对于模板单元来说，情况则有所不同。 虽然必须使用实例名称调用 systemctl enable 命令， 但是实际上添加到 .wants/ 或 .requires/ 目录中的软连接， 指向的却是模板单元(因为并不存在真正的单元实例文件)。 假设 getty@.service 文件中存在 WantedBy=getty.target 选项，那么 systemctl enable getty@tty2.service 命令将会创建一个 getty.target.wants/getty@tty2.service 软连接(指向 getty@.service)

设置此单元的附属单元， 可以设为一个空格分隔的单元列表。 表示当使用 systemctl enable 启用 或 systemctl disable 停用 此单元时， 也同时自动的启用或停用附属单元。

如果多次使用此选项， 那么每个选项所设置的附属单元列表 都会合并在一起。

仅对模板单元有意义， 用于指定默认的实例名称。 如果启用此单元时没有指定实例名称， 那么 将使用这里设置的名称。