systemd.unit翻译

SYSTEMD.UNIT(5)            systemd.unit                    SYSTEMD.UNIT(5)
名称
Systemd.unit - 单元配置
概要
systemd.service, systemd.socket, systemd.device, systemd.mount,     systemd.automount,          systemd.swap, systemd.target, systemd.path,     systemd.timer,systemd.snapshot
描述
一个单元的配置文件编码信息关于服务，套接字，设备，挂载点，交换文件或者分区，开始标签，文件系统路径或者时间控制和监控被systemd(1)。这个语法被XDG DesktopEntry Specification[1]授予。桌面文件，又受微软Windows的.ini文件所授予。

这个man pages 显示了所有单元类型的命令配置选项。这些配置选项您可以查看［Unit］或[Install] 章节关於单元文件。

除了能用的［Unit］和［Install］章节描述外，还可以参考其它章节，例如 ［Service］ 的服务单元。看respective man pages了解更多信息。

单元文件可能包含附加的选项在这些列表中。如果systemd 遇到一个未知的选项时，他将显示一个警告信息，但是继续加载这个单元。如果某个选项的前缀为X－，那么它将被systemd忽略.有些应用程序可能使用这些包含附加信息的单元文件。

布尔参数用在单元文件上可能会被写成变量的格式。比如正确将设置成字符串1，yes，true或者on是一样的。不正常将设置成字符串0，no，false 或者off 是一个的。
在单元文件中时间跨度值编码可能被写成变量格式。一个独立的数字指定时间为秒。如果后缀有时间单位,单位是你指定的。这个单元可以支持多个值进行关联，在这种情况下这些值将进行累加。例如：“50”指的是50秒；“2min200ms” 指的是2分钟加上200毫秒，i.e. 120200ms。下面的这些时间单位    你必须明白：s，min，h，d，w，ms，us。

空行和行首为＃或者；是被忽略的，这是用来做注释用的。行尾如果是反斜杠是与下面的行连起来一起读或者反斜杠替换为一个空格字符。这个用于比较长的行。

如果行首是.include后跟一个文件名，指定的文件将被解析在这一点上，确保文件包括有适当章节的头部在执行任何指令之前。

连同一个单位文件foo.service 一个目录 foo.service.wants/ 的存在。所有的单元链接从这样一个目录默认添加依赖项类型Wanted= 到这个单元。这是有用的单元等待其它的单元启动，不用修改他们单元的配置文件。想了解更详细关于Wanted=的语法如下。首先创建符号链接在.wants/目录，然后使用
systemctl enable 命令开启服务,在单元文件systemctl(1)工具从[Install]章节中读取信息。（如下）有一个类似功能的存在 requires= 的信赖性很好，这个目录的后缀是.requires/ 在这种情况下。

注意，虽然systemd将提供了一个灵活的依赖系统，各单元之间推荐使用这种功能只有稀疏的而不是靠技术,如总线或基于socket的活性化使依赖更含蓄，这两个结果是更简单、更灵活的系统。

一些单位名称反映路径中存在文件系统的名称空间。例如一个设备单元    dev-sda.service 反映一个设备节点/dev/sda在这个文件系统名称空间。如果这适用于一种特殊的方式来逃避使用路径名，则这个结果只作为文件名的一部分。基本上，给出一个路径，“／”被“－”所代替，所有的不可输出的字符和“－”    是被C－style “\x20”反替代。根目录“／“的代码是一个破折号，然尔初始化和结束“／”将被移除从所有路径转换的过程中。 这个转义是可逆的。

另外，单位可以被实例化当对模板文件进行排序时。这允许创建多个单元从一个配置文件。如果systemd 寻找一个单元配置文件，它将首先搜索文字单元名在这个文件系统中。如果结果没成功或者这个单元获得一个＠符，systemd 将查询单元临时共享的同名文件，但是这个实例串（i.e. ＠字符和    后缀两都的一部分）被移除。例如：如果一个服务[email protected]被请求并且没有没有文件被找到，systemd将查找[email protected]和实例化一个服务从配置文件中。

指定实例串在这个配置文件中，你可以使用特殊的%i说明符在很多配置选项中。其它的说明符如下：
表1. 在单元文件中可用的说明符
说明符
含义
详细
%u
完整的单元名
%N
非转义的单元名
％p
前缀名
指定的串在＠之前，i.e.”getty” 在example 上，“tty3”是实例名
％P
非转义前缀名
％i
实例名
在这个＠符和后缀之间的字符串
％I
非转义例名
％f
非转义文件名
如果这个非转义的实例名（如果设置）的前缀带(如果需要) /，或者这个前缀名与 / 目录相似。
%c
控制单元组的路径
％r
root控制systemd的组路径
%R
root控制systemd的组路径的父目录
％t
运行时套接字目录
要么/run（系统管理）要么$XDG_RUNTIME_DIR(用户管理)
％u
用户名
这是配置的名称的用户单位，或(如果没有设置)用户运行systemd实例
%h
用户家目录
这是配置用户单元的家目录，或(如果没有设置)用户运行systemd实例
%s
用户shell
这是配置用户单元的shell，或(如果没有设置)用户运行systemd实例
%m
机器ID
运行系统的机器ID，格式为字符串，看machine-id(5)了解更多信息
%b
引导ID
运行系统的引导ID，格式为字符串，看random(4)了解更多信息
H
主机名
运行系统的主机名
如果一个单元文件为空（i.e. 文件大小是0）或被指向到/dev/null，那么他的配置将不被加载或出现一种被加载的假状，并且不能被激活。使用一个有效的方法去完整的禁用一个单元，使它不可以手动启动。
这个单元文件的格式被Interface Stability Promise[2]覆盖。

OPTIONS
单元文件包括一个（Unit）章节，同时提供关於单元信息，但不信赖於单元类型。
Description=
一个用来自由描述单元的字符串。这是用于UIs显示单位名称的描述性信息
Documentation＝
空格分隔的列表引用文档的uri为本单位或其配置。接受只有uri的类型 httpd://，https://，file:，info:。想了解更多关于uri的语法看uri(7)
Requires=
配置需求依赖于其他单位。如果这个单元被激活，这里列出的单位也会被激活。如果其中一个其他单位被停用或其激活失败,本单元将被停用.这个选项可以指定超过一次，在这种情况下,要求对所有被创建列出的名    称都有依赖。注意,需求依赖关系不影响服务的顺序启动或停止。这必须被配置独立于After=或Before=选项。如果一个单元foo.service请求一个单元bar.service 将被配置Requires=，但没有事先配置After=或Before=，如果服务被激活，两个单元将同时被启动并在启动时没有任何延迟。通    常它是一个更好的选择，用Wants=代替Requires=是为了实现一个系统更健壮的处理失败的服务
注意,这种类型的依赖关系也可以被配置在配置文件以外的单位，添加一个软链接到.requires/ 目录来连接这个单元文件。更详细的看上面。
RequiresOverridable=
和Requires=类似。信赖项列在RequiresOverridable=不能满足或者启动失败是被忽略的，这个明显是被用户请求的。如果一开始是由一些信赖了间接或自动启动的单位，不是用户所请求的这种信赖性被满足，否则事务失败。因此，这个选项可以用来配置信赖关系，通常是荣幸的，除非有明确启动单元，在这种情况下他们是否失败是无关紧要的。
Requisite=, RequisiteOverridable=
Requisite=和RequisiteOverridable=类似，分别的。然而，如果一个单位列在这里是没有开始，他将不会被启动或者这个事务立即失败。
Wants=
       一个版本比较低的Requires=，如果是配置单元，那么这个单元列出的选项将开始。然而如果列出单元是启动失败或者不能被添加到事务中，这没有影响事务的有效性和完整性，这是推荐的启动方式，当一个单位启动到其它单元上时。
注意,这种类型的依赖关系也可以被配置在配置文件以外的单位，添加一个软链接到.wants/ 目录来连接这个单元文件。更详细的看上面。
BindsTo=
配置需求依赖关系，和Requires=的风格非常相似，然而除了这个行为它还声明这个单位是停止的当其它单位突然消失的时候，单元可能突然的，出人意料的消失如果一个服务的终止是它自己的选择，一个设备是不插电或者卸载挂载点没有在systemd中包含。
PartOf=
配置信赖类似于Requires=，但限于停止和重新启动的单位，当systemd停止或重启时，这个动作将被传播到这个单位。注意这是一个信赖的方法－发到这个单位不影响其它的单位。
Conflicts=
配置非需求信赖关系。如果一个单元有一个Conflicts=设置在另一个单位上，启动前将停止后者,反之亦然。注意，这个设置是独立的和正交的在After=和Before=的先后信赖关系上。
如果一个单元和另一个单元B相冲突，那么B也同时启动。事务要么失    败（如果两者都需要事务的一部分）或被修改是固定的（如果一个或两个工作不是一个必需的事务的一部分）。在后一种情况下的工作不是必须的将被删除，或者两者都不需要单位，这个冲突将要开始或者这个单元的冲突将被终止。
Before=, After=
配置单元之前的信赖关系。如果一个单元foo.service 设置了Before=bar.service，那么我两个单元将被开启，bar.service 的开启将延迟直到foo.service开启。注意，这个设置是独立的和正交的信赖关系当配置了Requires=。这是一个常见的模式包括单位名称After=和Requires=这两个选项，在这种情况下，单位列出的这些配置选项将在此之前开始。这个选项可以指定超过一次，在这种情况下，所有列出的名称都将按照信赖顺序被创建。After和Before=是相反的，例如，当After=确保配置    单元是开启后这个列出来的单元完成启动，Before=正好与之相反，例如配置单元完全启动前这个列出的单元将被启动。当两个单位之间产生依赖关系时，它们都将关闭，反过来这个启动顺序将被应用。例如，如果一个单元配置了After=在其它单元上，那么前者是停止在后者之前如果两者都是关闭的。如果一个带依赖顺序的单元在其它的单元关闭后启动，那么这个关闭的顺序是否在启动之前，是否有信赖性实际取决于类型    After=或者Before=。如果两个单元之前没有依赖顺序，那么他将同时关闭或者启动，无顺序将要发生。
OnFailure=
列出一个或者多个被激活的单元当这个单元处于‘failed’状态。
PropagatesReloadTo=, ReloadPropagatedFrom=
列出一个或者多个单位，重新加载请求的单位将被传播到其它的单位或者从其它单位进行传播。发布一个重新加载的请求在一个单元，它将自动刷新重载请求在所有单位，重新加载请求将通过这两信设置进行传播。
RequiresMountsFor=
以空格分隔列表的绝对路径。自动添加信赖项的类型Requires=和After=，对于所有挂载单位需要访问指定的路径。
OnFailureIsolate=
需要一个布尔参数。如果为true，列在OnFailure=的单元将被加入队列并且隔离模式，例如。所有单位中不是他的信赖将被停止。如果只是设置一个单一的单位，可以被列入OnFailure=中。默认为false
IgnoreOnIsolate=
需要一个布尔参数。如果为true,那么这个单位将不会被停止当隔离其它单位时，默认为false
IgnoreOnSnapshot=
需要一个布尔参数。如果为true，那么这个单位将不包含在快照中。默认值为true为设备和快照单位，false为其它单位。
StopWhenUnneeded=
需要一个布尔参数。如果为true，这个单元将被停止当他不再使用时。注意，为了最小化执行工作，systemd将不会停止，除非它们默认的单位与其它单位发生冲突，或者用户主动地请求他们关闭。如果设置了这个选项，一个单元将自动清理如果没有其他活动单位需要它，默认为false。
RefuseManualStart=, RefuseManualStop=
需要一个布尔参数。如果为true，这个单位只能间接激活或者不激活。在这种情况下直接启动或者终止用的请求都将被拒绝，但是如果开启或者停止是信赖于其它单位，开启或者终止都将成功。这主要是有一个安全特性来保证用户并不意外激活单元，并不打算明确的被明确的激活，不是不小心停用单位，不是为了被停用。这个选项默认为false。
AllowIsolate=
需要一个布尔参数。如果值为true,这个单位可能使用systemctl isolate 命令。相反将被拒绝。它可能是一个好的方法，除了目标单位以外的都将被禁用，应使用类似于init系统的运行级别来运行SysV，只是作为一项预防措施来避免无法使用系统的状况。这个选项默认为false。
DefaultDependencies=
需要一个布尔参数。如果值为true（默认）,一些默认的依赖性将隐式的创建为单位。实际上创建依赖关系取决於单位类型。例如服务单位，这些依赖关系要确保该服务已经开始，只有在基本系统初始化完成和正确    地终止系统关机。看各自的man page页了解详情。通常只有服务参与早期的引导或者晚关机应该设置这个选项为false。强烈建议启用这个选项对于大多数常见的单位。如果设置为false，这个选项没有禁用所有隐式的信赖项，只是非必要的。
JobTimeoutSec=
当客户正在等待一个工作被这个单位完成时，时间在指定的时间后。如果这个时间限制到达后，那么这个作业将被取消，这个单位将不会改变状态或者进入“failed”模式。这个值默认为0（任务超时被禁用），除了设备单位。注：这个超时是独立于任何单位－具体工作的超时（例如，超时设置Timeout=为服务单位）不会影响到单位本身，只有在工作上才有    可能等待它。换句话说：指定单位超时对取消单位状态改变是有用的，并且恢复它们。工作超时设定这个选项是有用的，但是只有中止这个工    作单位状态的改变。
ConditionPathExists=,ConditionPathExistsGlob=,ConditionPathIsDirectory=,     ConditionPathIsSymbolicLink=,ConditionPathIsMountPoint=,
ConditionPathIsReadWrite=,     ConditionDirectoryNotEmpty=,     ConditionFileNotEmpty=, ConditionFileIsExecutable=,         ConditionKernelCommandLine=,ConditionVirtualization=,ConditionSecurity=,     ConditionCapability=, ConditionHost=, ConditionNull=
在开始前一个单元验证指定的条件为true。如果它是不正确的启动单元    将被忽略，然而所有的信赖顺序仍然不受任何影响。一个失败的情况不会导致单位被移动到一个失败状态。这个条件检查当时队列中将要开始被执行的任务。
ConditionPathExists= 一个文件存在的条件是在检查一个单元启动之前。如果指定的绝对路径名不存在，那这个条件将失败。如果这个绝对路径名传递给ConditionPathExists=的前缀是一个感叹号（‘！’），测试是否定的，只有这个路径不存在这个单元才开始。
ConditionPathExistsGlob=和ConditionPathExists=类似，但会检查是否存在至少一个文件或目录能够匹配指定的通配模式。
ConditionPathIsDirectory=和ConditionPathExists=类似，但会验证特定的路径是否存在和是否是目录。
ConditionPathIsSymbolicLink和ConditionPathExists=类似，但会验证特定的路径是否存在和是否是软链接。
ConditionPathIsMountPoint=和ConditionPathExists=类似，但会验证特定的路径是否存在和是否是挂载点。
ConditionPathIsReadWrite=和ConditionPathExists= 类似，但会验证底层的文件系统是否可读可写（例如不为只读）。
ConditionDirectoryNotEmpty=和ConditionPathExists=类似，但会验证特定的路径是否存在和是否是非空目录。
ConditionFileNotEmpty= 和ConditionPathExists=类似，但会验证特定的路径是否存在和指定一个非零大小的常规文件
ConditionFileIsExecutable=和 ConditionPathExists= 类似，但会验证特定的路径是否存在和是否是一个可执行的常规文件。
类似的，ConditionKernelCommandLine=可以用来检查是否一个特定的内核命令行选项被设置（或者说前缀感叹号没有设置）。这个参数必须是一个单词，或是一个任务（例如两个单词，隔离’=’）。在前一种情况下内    核命令行是寻找这个词的出现或者是左手边的一项任务。在后一种情况下精确的寻找右手边或是左手边匹配的任务。
ConditionVirtualization=可用于检查系统是否可以在虚拟环境中执行和有选择性的测试它是否可以实现。需要使用布尔值来检查是否可以在任何虚拟化环境中执行，或使用一个vm和container 来测试一个通用型的虚    拟化解决方案，或者选择qemu，kvm，vmware，microsoft，oracle，xen，    bochs，chroot，openvz，lxc，lxc-libvirt，systemd-nspawn其中之一来有针对性的测试。如果多个虚拟化技术只考虑最内层嵌套。那么这个测试可能被追加一个感叹号。
ConditionSecurity=可以用来检查系统上的安全模块是否启用。目前唯一公认的是selinux。这个测试可能被追加一个感叹号。
ConditionCapability=可以用来检查是否存在特定的能力在服务管理的性能边界设置上（这并不检查是否有能力，实际上是允许和有效的集合是否可用，看capabilities(7) 了解详情）。通过能力的名字如CAP_MKNOD，可以用一个感叹号来否定检查。
ConditionHost=可以用主机名或机器ID来匹配主机。这不是需要一个主机名的字符串，而是用来测试设置主机名的返回值gethostname(2)，或机器ID的格式为字符串（看 machine-id(5)）。这个测试可能被追加一个感叹号。
最后，ConditionNull=可以添加一个常数条件检查值到这个单位。它需要一个布尔参数。如果设置为false这个条件将总是失败，相反则成功。
如果多个条件被指定，那么所有的应用单元都将被执行（例如。一个合    乎逻辑的应用）。条件检查可以加上前缀管道符号（｜），在这种情况下一个条件成为一个触发条件。如果至少有一个触发条件是定义单元然后    单位将被执行，如果至少一个触发条件应用和所有的非触发条件。如果你的前缀的参数是管道符和感叹号，那么管道符第一，感叹号第二。除了 ConditionPathIsSymbolicLink=，所有路径的检查都允许软链接。
SourcePath=
一个用来存放单元配置文件的一个路径。这主要是用于实现生成程序的工具，将外部配置文件的格式转换为本地单元文件。因此这个功能不应该用在正常的单位上。
单元文件可能包含一［Install］章节，包含这个单元的安装信息。当systemd(1)    正在运行时，这个章节将不被解释。它专门用于systemctl（1）工具在安装    单元期间使用enable和disable命令：
Alias=
这个单位在安装时的其它名字。这里列出的名称必须具有相同后缀（类型）作为单位的文件名称。这个选项可以指定多次，在这种情况下，所有列出的名称都可用。在安装时，systemctl enable将创建软链接用这些名称作为单元文件名。
WantedBy=, RequiredBy=
分别的为一个单元安装一个符号链接在.wants/或.requires/的子目录上，这个效果是当列出的单元名称是被激活，那么这单元列出也将被激活。WantedBy=foo.service一个服务bar.service 几乎等于    Alias=foo.service.wants/bar.service在相同文件中。
Also=
当这个单元被安装后附加的单元。如果用户要求在安装时配置这个选项，systemctl enable 将自动的安装单元并且列出这个选项。
SEE  ALSO
systemd(1), systemctl(8), systemd.special(7), systemd.service(5),     systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5),
systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5),     systemd.snapshot(5), capabilities(7)
注意
1. XDG 桌面入口规范          
   http://standards.freedesktop.org/desktop-entry-spec/latest/

2. 接口稳定性承诺
    http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise

systemd                                                       SYSTEMD.UNIT(5)