翻译

描述

名称以“.service”结尾的单元配置文件对有关由systemd控制和监督的进程的信息进行编码。

此手册页列出了特定于此单元类型的配置选项。有关所有单元配置文件的常用选项，请参阅systemd.unit（5）。通用配置项在通用“[Unit]”和“[Install]”部分中配置。特定于服务的配置选项在“[服务]”部分中配置。

systemd.exec（5）中列出了其他选项，它们定义了执行命令的执行环境，systemd.kill（5）中定义了服务进程的终止方式，并在systemd.resource-control(5)，用于配置服务进程的资源控制设置。

如果以特定名称请求服务但未找到单元配置文件，则systemd将查找具有相同名称的SysV init脚本（删除.service后缀），并从该脚本动态创建服务单元。这对于与SysV的兼容性非常有用。请注意，此兼容性非常全面，但不是100％。有关不兼容性的详细信息，请参阅与SysV文档的不兼容性。

systemd-run（1）命令允许从命令行动态和瞬时创建.service和.scope单元。

.service 模板

systemd服务可以通过“service@argument.service”语法获取单个参数。这种服务称为“实例化”服务，而没有参数参数的单元定义称为“模板”。一个示例可以是dhcpcd @ .service服务模板，它将网络接口作为参数来形成实例化服务。在服务文件中，可以使用％-specifiers访问此参数或“实例名称”。有关详细信息，请参阅systemd.unit（5）。

自动依赖

隐含的依赖关系

隐式添加以下依赖项：

Type = dbus设置的服务自动获取类型Requires =和After = on dbus.socket的依赖关系。

套接字激活的服务在激活.socket单元后通过自动After =依赖自动排序。服务还引入套接字中列出的所有.socket单元=通过自动Wants =和After =依赖项。

如systemd.exec（5）和systemd.resource-control（5）中所述，可以添加其他隐式依赖项作为执行和资源控制参数的结果。

默认依赖项

除非设置了DefaultDependencies = no，否则将添加以下依赖项：

服务单元将具有类型为Requires =和After = on sysinit.target的依赖项，类型为After = on basic.target的依赖项以及类型为Conflicts =和Before = on shutdown.target的依赖项。这些确保正常的服务单元引入基本系统初始化，并在系统关闭之前彻底终止。只有早期启动或延迟系统关闭所涉及的服务才能禁用此选项。

默认情况下，为模板单元命名的实例化服务单元（即名称中带有“@”的服务单元）分配每个模板切片单元（参见systemd.slice（5）），其中包含特定模板的所有实例。此切片通常在关闭时与所有模板实例一起停止。如果不需要，请在模板单元中设置DefaultDependencies = no，并定义您自己的每个模板切片单元文件，该文件也设置DefaultDependencies = no，或者在模板单元中设置Slice = system.slice（或其他合适的切片）。另请参见systemd.resource-control（5）。

选项

Service 文件必须包含“[Service]”部分，其中包含有关服务及其监督的过程的信息。本节中可能使用的许多选项与其他单元类型共享。这些选项记录在systemd.exec（5），systemd.kill（5）和systemd.resource-control（5）中。服务单位的“[Service]”部分特定的选项如下：

Type=

配置此服务单元的过程启动类型。选择simple, exec, forking, oneshot, dbus, notify 或idle之一：

如果设置为simple（默认情况下，如果指定了ExecStart =但Type =也不是BusName =），则服务管理器将在主服务进程分离后立即考虑启动该单元。预计使用ExecStart =配置的进程是服务的主要进程。在此模式下，如果进程为系统上的其他进程提供功能，则应在服务启动之前安装其通信通道（例如，systemd设置的套接字，通过套接字激活），因为服务管理器将立即开始跟随-up单元，在创建主服务进程之后，在执行服务的二进制文件之前。请注意，这意味着即使无法成功调用服务的二进制文件，简单服务的systemctl start命令行也会报告成功（例如，因为所选的User =不存在，或者缺少服务二进制文件）。

exec类型与simple类似，但服务管理器会认为在执行主服务二进制文件后立即启动了该单元。服务经理将推迟后续单位的启动，直至该点。（或者换句话说：在fork（）返回后，简单地继续执行其他作业，而exec在服务进程中的fork（）和execve（）成功之前不会继续。）请注意，这意味着exect服务的systemctl启动命令行将无法成功调用服务的二进制文件时报告失败（例如，因为所选的User =不存在，或者服务二进制文件丢失）。

如果设置为分叉，则预期使用ExecStart =配置的进程将调用fork（）作为其启动的一部分。预期父进程在启动完成并且所有通信通道都已设置时退出。子进程继续作为主服务进程运行，服务管理器将在父进程退出时考虑启动该单元。这是传统UNIX服务的行为。如果使用此设置，建议还使用PIDFile =选项，以便systemd可以可靠地识别服务的主进程。一旦父进程退出，systemd将继续启动后续单元。

oneshot的行为类似于简单;但是，服务经理会在主进程退出后考虑该单元。然后它将启动后续单位。 RemainAfterExit =对此类服务特别有用。如果既未指定Type =也未指定ExecStart =，则Type = oneshot是隐含的默认值。请注意，如果在没有RemainAfterExit =的情况下使用此选项，则服务将永远不会进入“活动”单元状态，而是直接从“激活”转换为“停用”或“死”，因为没有配置应继续运行的进程。特别是这意味着在这种类型的服务运行后（并且RemainAfterExit =未设置）它将不会显示为之后启动，而是显示为已死。

dbus的行为类似于简单;但是，预计该服务在D-Bus总线上获取一个名称，由BusName =配置。在获得D-Bus总线名称后，systemd将继续启动后续单元。配置了此选项的服务单元隐式地获得了对dbus.socket单元的依赖性。如果指定了BusName =，则此类型是缺省值。

通知的行为类似于exec;但是，预计服务在启动完成后通过sd_notify（3）或等效呼叫发送通知消息。 systemd将在发送此通知消息后继续启动后续单元。如果使用此选项，则应将NotifyAccess =（见下文）设置为打开对systemd提供的通知套接字的访问权限。如果NotifyAccess =缺失或设置为none，则将强制设置为main。请注意，如果与PrivateNetwork = yes结合使用，则当前Type = notify将不起作用。

闲置行为非常类似于简单;但是，服务程序的实际执行会延迟，直到调度所有活动作业为止。这可用于避免将shell服务的输出与控制台上的状态输出交错。请注意，此类型仅用于改进控制台输出，它不能用作常规单元排序工具，并且此服务类型的效果受到5秒超时的影响，之后无论如何都会调用服务程序。

通常建议在任何可能的情况下使用Type = simple作为长期运行的服务

RemainAfterExit=

采用一个布尔值，指定即使退出所有进程，服务是否应被视为活动状态。默认为否

GuessMainPID=

采用一个布尔值，指定systemd是否应该尝试猜测服务的主PID，如果无法可靠地确定它。除非设置了Type = forking且未设置PIDFile =，否则将忽略此选项，因为对于其他类型或使用显式配置的PID文件，主PID始终是已知的。如果守护进程包含多个进程，则猜测算法可能会得出错误的结论。如果无法确定主PID，则故障检测和服务的自动重启将无法可靠地运行。默认为是。

PIDFile=

采用引用服务的PID文件的路径。对于Type =设置为forking的服务，建议使用此选项。指定的路径通常指向/ run /下面的文件。如果指定了相对路径，则因此以/ run /为前缀。服务管理器将在启动服务后从该文件中读取服务主进程的PID。服务管理器不会写入此处配置的文件，但如果服务仍然存在，它将在服务关闭后删除该文件。 PID文件不需要由特权用户拥有，但如果它由非特权用户拥有，则会强制执行其他安全限制：该文件可能不是由不同用户拥有的文件的符号链接（既不直接也不间接），PID文件必须引用已属于该服务的进程。

BusName=

获取此服务可访问的D-Bus总线名称。对于Type =设置为dbus的服务，此选项是必需的。

ExecStart=

具有在启动此服务时执行的参数的命令。根据下面描述的规则将该值拆分为零个或多个命令行（请参阅下面的“命令行”部分）。

除非Type =是oneshot，否则必须给出一个命令。当使用Type = oneshot时，可以指定零个或多个命令。可以通过在同一指令中提供多个命令行来指定命令，或者，可以多次指定该指令具有相同的效果。如果将空字符串分配给此选项，则重置要启动的命令列表，此选项的先前分配将不起作用。如果未指定ExecStart =，则服务必须具有RemainAfterExit = yes且至少一个ExecStop =行集。（缺少ExecStart =和ExecStop =的服务无效。）

对于每个指定的命令，第一个参数必须是可执行文件的绝对路径或没有任何斜杠的简单文件名。（可选）此文件名可以带有许多特殊字符作为前缀：

“@”，“ - ”，“：”和“+”/“！”/“!!”中的一个可以一起使用，它们可以按任何顺序出现。但是，只有“+”，“！”，“!!”中的一个可以一次使用。请注意，其他命令行设置也支持这些前缀，即ExecStartPre =，ExecStartPost =，ExecReload =，ExecStop =和ExecStopPost =。

如果指定了多个命令，则按照它们在单元文件中出现的顺序依次调用这些命令。如果其中一个命令失败（并且没有前缀“ - ”），则不执行其他行，并且该单元被视为失败。

除非设置了Type = forking，否则通过此命令行启动的进程将被视为守护程序的主进程。

ExecStartPre=, ExecStartPost=

分别在ExecStart =中的命令之前或之后执行的其他命令。语法与ExecStart =相同，除了允许多个命令行并且串行地依次执行命令。

如果这些命令中的任何一个（没有以“ - ”为前缀）失败，则不执行其余命令并且该单元被视为失败。

ExecStart =命令仅在所有ExecStartPre =命令之后运行，这些命令未成功以“ - ”为前缀退出。

ExecStartPost =命令仅在ExecStart =中指定的命令成功调用后运行，由Type =确定（即已为Type = simple或Type = idle启动进程，最后一个ExecStart =进程已成功退出Type = oneshot ，对于Type = forking，初始进程成功退出，对Type = notify发送“READY = 1”，或者对Type = dbus采用BusName =。

请注意，ExecStartPre =可能不会用于启动长时间运行的进程。由ExecStartPre =调用的进程分叉的所有进程将在下一个服务进程运行之前被终止。

请注意，如果在ExecStartPre =，ExecStart =或ExecStartPost =中指定的任何命令失败（并且没有前缀“ - ”，请参见上文）或在服务完全启动之前超时，则继续执行ExecStopPost中指定的命令= ，跳过ExecStop =中的命令。

ExecCondition=

在ExecStartPre =中的命令之前执行的可选命令。语法与ExecStart =相同，除了允许多个命令行并且串行地依次执行命令。

行为类似于ExecStartPre =和条件检查混合：当ExecCondition =命令以退出代码1到254（包括）退出时，将跳过其余命令并且单元未标记为失败。但是，如果ExecCondition =命令以255退出或异常（例如超时，被信号杀死等），则该单元将被视为失败（并且将跳过剩余的命令）。退出代码0或匹配SuccessExitStatus =的代码将继续执行到下一个命令。

关于不在ExecStartPre =中运行长时间运行的进程的相同建议也适用于ExecCondition =。 ExecCondition =还将运行ExecStopPost =中的命令，作为停止服务的一部分，在任何非零或异常退出的情况下，如上所述。

ExecReload=

要执行的命令以在服务中触发配置重新加载。此参数采用多个命令行，遵循与ExecStart =上面描述的相同的方案。使用此设置是可选的。此处支持说明符和环境变量替换，遵循与ExecStart =相同的方案。

设置了一个额外的特殊环境变量：如果已知，则将$ MAINPID设置为守护程序的主进程，并且可以用于以下命令行：

/ bin / kill -HUP $ MAINPID
但请注意，通过发送信号重新加载守护程序（与上面的示例行一样）通常不是一个好的选择，因为这是一个异步操作，因此不适合命令多个服务相互重新加载。强烈建议将ExecReload =设置为一个命令，该命令不仅会触发守护程序的配置重新加载，还会同步等待它完成。

ExecStop=

要执行以停止通过ExecStart =启动服务的命令。此参数采用多个命令行，遵循与ExecStart =上面描述的相同的方案。使用此设置是可选的。运行此选项中配置的命令后，暗示服务已停止，并且根据KillMode =设置终止为其剩余的任何进程（请参阅systemd.kill（5））。如果未指定此选项，则在请求服务停止时，通过发送KillSignal =中指定的信号来终止该过程。支持说明符和环境变量替换（包括$ MAINPID，见上文）。

请注意，为此设置指定一个命令通常是不够的，该命令仅要求服务终止（例如，通过为其排队某种形式的终止信号），但不等待它这样做。由于服务的其余进程在命令退出后立即根据KillMode =和KillSignal =被杀死，这可能不会导致干净停止。因此，指定的命令应该是同步操作，而不是异步操作。

请注意，ExecStop =中指定的命令仅在服务首次成功启动时执行。如果服务从未启动过，或者启动失败，则不会调用它们，例如，因为ExecStart =，ExecStartPre =或ExecStartPost中指定的任何命令失败（并且没有以“ - ”为前缀），见上文）或超时。当服务无法正常启动并再次关闭时，使用ExecStopPost =调用命令。另请注意，如果服务成功启动，则始终执行停止操作，即使服务中的进程自行终止或被终止也是如此。必须准备停止命令来处理这种情况。如果systemd在调用stop命令时知道主进程退出，则将取消设置$ MAINPID。

服务重启请求实现为停止操作，然后是启动操作。这意味着在服务重启操作期间执行ExecStop =和ExecStopPost =。

建议将此设置用于与请求干净终止的服务通信的命令。对于事后清理步骤，请使用ExecStopPost =。

ExecStopPost=

服务停止后执行的其他命令。这包括使用ExecStop中配置的命令的情况，其中服务没有定义任何ExecStop =，或服务意外退出的情况。此参数采用多个命令行，遵循与ExecStart =所述相同的方案。使用这些设置是可选的。支持说明符和环境变量替换。请注意 - 与ExecStop =不同 - 当服务无法正常启动并再次关闭时，将调用使用此设置指定的命令。

建议使用此设置进行清理操作，即使服务无法正常启动也应执行清理操作。使用此设置配置的命令需要能够运行，即使服务中途启动失败并且未完全初始化数据。由于在执行使用此设置指定的命令时服务的进程已经终止，因此它们不应尝试与它们通信。

请注意，使用此设置配置的所有命令都将使用服务的结果代码调用，以及主进程的退出代码和状态，在$ SERVICE_RESULT，$ EXIT_CODE和$ EXIT_STATUS环境变量中设置，请参阅systemd.exec （5）详情。

RestartSec=

配置重新启动服务之前的睡眠时间（使用Restart =配置）。以秒为单位获取无单位值，或以“5min 20s”为单位获取时间跨度值。默认为100ms。

TimeoutStartSec

配置等待启动的时间。如果守护程序服务未在配置的时间内发出启动完成信号，则该服务将被视为失败并将再次关闭。以秒为单位获取无单位值，或以“5分20秒”为单位获取时间跨度值。传递“无穷大”以禁用超时逻辑。默认情况下，来自管理器配置文件的DefaultTimeoutStartSec =，除非使用Type = oneshot，在这种情况下默认情况下禁用超时（请参阅systemd-system.conf（5））。

如果Type = notify的服务发送“EXTEND_TIMEOUT_USEC = …”，则可能导致开始时间超出TimeoutStartSec =。第一次收到此消息必须在超出TimeoutStartSec =之前发生，并且一旦开始时间超出TimeoutStartSec =，服务管理器将允许服务继续启动，前提是服务在指定的时间间隔内重复“EXTEND_TIMEOUT_USEC = …”直到服务启动状态由“READY = 1”结束。（见sd_notify（3））

TimeoutStopSec=

此选项有两个用途。首先，它配置等待每个ExecStop =命令的时间。如果其中任何一个超时，则跳过后续的ExecStop =命令，SIGTERM将终止该服务。如果未指定ExecStop =命令，则服务立即获取SIGTERM。其次，它配置等待服务本身停止的时间。如果它没有在指定的时间内终止，它将被SIGKILL强制终止（参见systemd.kill（5）中的KillMode =）。以秒为单位获取无单位值，或以“5分20秒”为单位获取时间跨度值。传递“无穷大”以禁用超时逻辑。默认为DefaultTimeoutStopSec =来自管理器配置文件（请参阅systemd-system.conf（5））。

如果Type = notify的服务发送“EXTEND_TIMEOUT_USEC = …”，则可能导致停止时间超出TimeoutStopSec =。第一次收到此消息必须在超出TimeoutStopSec =之前发生，并且一旦停止时间超出TimeoutStopSec =，服务管理器将允许服务继续停止，前提是服务在指定的时间间隔内重复“EXTEND_TIMEOUT_USEC = …” ，或终止自身（见sd_notify（3））。

TimeoutAbortSec=

此选项配置由于看门狗超时而中止服务时等待服务终止的时间（请参阅WatchdogSec =）。如果服务具有短的TimeoutStopSec =此选项可用于为系统提供更多时间来编写服务的核心转储。到期时，SIGKILL将强制终止服务（参见systemd.kill（5）中的KillMode =）。在这种情况下，核心文件将被截断。使用TimeoutAbortSec =为每个服务的核心转储设置合理的超时，该超时足以写入所有预期数据，同时还足够短以在适当的时间处理服务故障。

以秒为单位获取无单位值，或以“5分20秒”为单位获取时间跨度值。传递一个空值以跳过专用的看门狗中止超时处理并回退TimeoutStopSec =。传递“无穷大”以禁用超时逻辑。默认为DefaultTimeoutAbortSec =来自管理器配置文件（请参阅systemd-system.conf（5））。

TimeoutSec=

将TimeoutStartSec =和TimeoutStopSec =配置为指定值的简写。

TimeoutCleanSec=

配置通过systemctl clean …请求的清理操作的超时，有关详细信息，请参阅systemctl（1）。采用通常的时间值并默认为无穷大，即默认情况下不应用超时。如果配置了超时，则在超时时强制中止清除操作，可能会在磁盘上留下资源。

RuntimeMaxSec=

配置服务运行的最长时间。如果使用此服务并且服务已激活超过指定时间，则它将终止并进入故障状态。请注意，此设置对Type = oneshot服务没有任何影响，因为它们在激活完成后立即终止。传递“infinity”（默认值）以配置无运行时限制。

如果Type = notify的服务发送“EXTEND_TIMEOUT_USEC = …”，则可能导致运行时扩展到RuntimeMaxSec =之外。第一次收到此消息必须在超过RuntimeMaxSec =之前发生，并且一旦运行时间超出RuntimeMaxSec =，服务管理器将允许服务继续运行，前提是服务在指定的时间间隔内重复“EXTEND_TIMEOUT_USEC = …” 通过“STOPPING = 1”（或终止）实现服务关闭。（见sd_notify（3））。

WatchdogSec=

配置服务的监视程序超时。启动完成后激活看门狗。该服务必须定期用“WATCHDOG = 1”调用sd_notify（3）（即“保持活动ping”）。如果两次此类调用之间的时间大于配置的时间，则服务将处于失败状态，并且将以SIGABRT（或WatchdogSignal =指定的信号）终止。通过将Restart =设置为on-failure，on-watchdog，on-abnormal或始终，服务将自动重新启动。此处配置的时间将传递给WATCHDOG_USEC =环境变量中的已执行服务进程。如果为服务启用了监视程序支持，这允许守护程序自动启用保持活动的ping操作。如果使用此选项，则应将NotifyAccess =（见下文）设置为打开对systemd提供的通知套接字的访问权限。如果未设置NotifyAccess =，则将隐式设置为main。默认为0，禁用此功能。该服务可以检查服务管理器是否期望看门狗保持活动通知。有关详细信息，请参阅sd_watchdog_enabled（3）。 sd_event_set_watchdog（3）可用于启用自动监视程序通知支持。

Restart=

配置在服务进程退出，终止或超时时是否应重新启动服务。服务进程可以是主服务进程，但也可以是使用ExecStartPre =，ExecStartPost =，ExecStop =，ExecStopPost =或ExecReload =指定的进程之一。当进程死亡是系统操作（例如服务停止或重新启动）的结果时，服务将不会重新启动。超时包括错过看门狗“keep-alive ping”截止日期以及服务启动，重新加载和停止操作超时。

采取no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. 。如果设置为no（默认值），则不会重新启动该服务。如果设置为on-success，则仅在服务进程干净地退出时才会重新启动。在此上下文中，干净退出表示退出代码为0，或者是SIGHUP，SIGINT，SIGTERM或SIGPIPE信号之一，此外还有退出状态和SuccessExitStatus =中指定的信号。如果设置为on-failure，则当进程以非零退出代码退出时，服务将重新启动，由一个信号（包括核心转储，但不包括上述四个信号）终止，当一个操作（如服务）超时）超时，以及触发配置的看门狗超时。如果设置为on-abnormal，则当信号（包括核心转储，不包括上述四个信号），操作超时或触发看门狗超时终止进程时，将重新启动服务。如果设置为on-abort，则仅当服务进程因未被指定为干净退出状态的未被捕获信号而退出时，服务才会重新启动。如果设置为on-watchdog，则仅当服务的监视程序超时到期时才会重新启动该服务。如果设置为always，则服务将重新启动，无论它是否干净地退出，信号异常终止或超时。
…
…
…

SuccessExitStatus=

获取退出状态定义列表，除了正常成功的退出代码0和信号SIGHUP，SIGINT，SIGTERM和SIGPIPE之外，当主服务进程返回时，将被视为成功终止。退出状态定义可以是数字退出代码，终止代码名称或终止信号名称，以空格分隔。有关终止代码名称列表，请参阅systemd.exec（5）中的“进程退出代码”部分（对于此设置，只应使用不带“EXIT_”或“EX_”前缀的部分）。有关信号名称列表，请参阅signal（7）。

此选项可能会出现多次，在这种情况下，合并成功退出状态列表。如果将空字符串分配给此选项，则重置列表，此选项的所有先前分配将不起作用。

示例1.具有SuccessExitStatus =设置的服务

SuccessExitStatus = TEMPFAIL 250 SIGUSR1
退出代码75（TEMPFAIL），250和终止信号SIGKILL被认为是干净的服务终端。

RestartPreventExitStatus=

获取退出状态定义列表，当主服务进程返回时，将阻止自动服务重新启动，无论使用Restart =配置的重新启动设置如何。退出状态定义可以是数字退出代码或终止信号名称，并以空格分隔。默认为空列表，因此默认情况下，配置的重新启动逻辑不会排除退出状态。例如：

RestartPreventExitStatus = 1 6 SIGABRT
确保退出代码1和6以及终止信号SIGABRT不会导致自动服务重启。此选项可能会出现多次，在这种情况下，合并了重启防止状态列表。如果将空字符串分配给此选项，则会重置列表，此选项的所有先前分配将不起作用。

请注意，此设置对通过ExecStartPre =，ExecStartPost =，ExecStop =，ExecStopPost =或ExecReload =配置的进程没有影响，但仅限于主服务进程，即ExecStart调用的进程=或（取决于Type =，PIDFile） =，…）否则配置的主进程。

RestartForceExitStatus=

获取退出状态定义列表，当主服务进程返回时，将强制自动重新启动服务，无论使用Restart =配置的重新启动设置如何。参数格式类似于RestartPreventExitStatus =。

RootDirectoryStartOnly=

采用布尔参数。如果为true，则使用RootDirectory =选项配置的根目录（有关详细信息，请参阅systemd.exec（5））仅适用于使用ExecStart =启动的进程，而不应用于其他各种ExecStartPre =，ExecStartPost =， ExecReload =，ExecStop =和ExecStopPost =命令。如果为false，则以相同方式将设置应用于所有已配置的命令。默认为false。

NonBlocking=

为通过基于套接字的激活传递的所有文件描述符设置O_NONBLOCK标志。如果为true，则所有文件描述符> = 3（即除stdin，stdout，stderr之外的所有文件描述符），不包括通过文件描述符存储逻辑传递的文件描述符（详见FileDescriptorStoreMax =），将设置O_NONBLOCK标志，因此为非阻止模式。此选项仅与套接字单元一起使用，如systemd.socket（5）中所述，并且对先前保存在文件描述符存储中的文件描述符没有影响。默认为false。

NotifyAccess=

控制对服务状态通知套接字的访问，可通过sd_notify（3）调用访问。采用none（默认值），main，exec或all之一。如果不是，则不从服务进程接受任何守护程序状态更新，则忽略所有状态更新消息。如果是main，则仅接受从服务的主进程发送的服务更新。如果是exec，则只接受来自其中一个Exec * =命令的任何主进程或控制进程发送的服务更新。如果全部，则接受来自服务控制组的所有成员的所有服务更新。应该将此选项设置为在使用Type = notify或WatchdogSec =时打开对通知套接字的访问（参见上文）。如果使用了这些选项但未配置NotifyAccess =，则会将其隐式设置为main。

请注意，仅当PID 1处理消息时发送过程仍然存在，或者服务管理器明确地运行时跟踪发送过程时，sd_notify（）通知才能正确归因于单元。如果服务管理器最初分离该进程，即在与main或exec匹配的所有进程上，则后者就是这种情况。相反，如果单元的辅助进程发送sd_notify（）消息并立即退出，则服务管理器可能无法将消息正确地归属到单元，因此将忽略它，即使NotifyAccess = all已为其设置

Sockets=

指定此服务从服务启动时继承套接字文件描述符的套接字单元的名称。通常，没有必要使用此设置，因为所有套接字文件描述符的单位与服务的名称相同（当然，不同的单位名称后缀）将传递给生成的进程。

请注意，相同的套接字文件描述符可以同时传递给多个进程。另请注意，传入的套接字流量可能会激活不同的服务，而不是最终配置为继承套接字文件描述符的服务。或者，换句话说：.socket单元的Service =设置不必与它所引用的.service的Sockets =设置的倒数相匹配。

此选项可能会出现多次，在这种情况下，合并插槽单元列表。请注意，一旦设置，则不支持再次清除套接字列表（例如，通过将空字符串分配给此选项）。

FileDescriptorStoreMax=

使用sd_pid_notify_with_fds（3）的“FDSTORE = 1”消息配置服务管理器中可以存储多少文件描述符。这对于实现可在显式请求或崩溃后重新启动而不会丢失状态的服务非常有用。在重启期间不应关闭的任何打开的套接字和其他文件描述符都可以这种方式存储。应用程序状态可以序列化为/ run中的文件，或者更好，存储在memfd_create（2）内存文件描述符中。默认为0，即没有文件描述符可以存储在服务管理器中。从特定服务传递到服务管理器的所有文件描述符将在下次服务重新启动时传递回服务的主进程。传递给服务管理器的任何文件描述符在它们上面看到POLLHUP或POLLERR时自动关闭，或者当服务完全停止且没有作业排队或正在执行时。如果使用此选项，则应将NotifyAccess =（参见上文）设置为打开对systemd提供的通知套接字的访问权限。如果未设置NotifyAccess =，则将隐式设置为main。

USBFunctionDescriptors=

配置包含USB FunctionFS描述符的文件的位置，以实现USB小工具功能。这仅与配置了ListenUSBFunction =的套接字单元一起使用。打开后，该文件的内容将写入ep0文件。

USBFunctionStrings=

配置包含USB FunctionFS字符串的文件的位置。行为类似于USBFunctionDescriptors =above。

OOMPolicy=

配置内存不足（OOM）杀手策略。在Linux上，当内存变得稀缺时，内核可能会决定终止正在运行的进程以释放内存并降低内存压力。此设置采用继续，停止或终止之一。如果设置为继续并且内核的OOM杀手杀死了服务进程，则会记录该服务但服务仍在继续运行。如果设置为停止，则会记录事件，但服务管理器会彻底终止该服务。如果设置为kill并且其中一个服务的进程被OOM杀手杀死，则内核被指示杀死该服务的所有剩余进程。默认为设置Default.OMPolicy =在system.conf（5）中设置为，但Delegate =打开的服务除外，它默认为继续。

使用OOMScoreAdjust =设置来配置单元的进程是否应被视为Linux OOM杀手逻辑的进程终止的首选或不太优选的候选进程。有关详细信息，请参阅systemd.exec（5）。

其他:参考官方手册

官方手册:

systemd.service

linux systemd.service说明相关推荐

linux 7 services设定,CENTOS/RHEL7系统中设置SYSTEMD SERVICE的ULIMIT资源限制
8种机械键盘轴体对比本人程序员,要买一个写代码的键盘,请问红轴和茶轴怎么选? 在bash中,有个ulimit命令,提供了对shell及该shell启动的进程的可用资源控制.主要包括打开文档描述符数量 ...
linux 7 services设定,CentOS 7 systemd service 设置limit，不生效问题
问题简述:Centos7下修改系统的最大文件打开数的时候,对系统启动的进程不生效问题详述:Centos7下需修改系统最大文件打开数为100000,进程数为50000,于是做了如下操作说明:此问题 ...
如何编写一个Systemd Service(转)
转自 https://segmentfault.com/a/1190000014740871 0x01 什么是Systemd Service Systemd 服务是一种以 .service 结尾的单元 ...
linux -- control service and daemon process
linux -- control service and daemon process 一.几个重要概念的讲解 1.systemd 系统启动和服务器进程由 systemd 系统和服务管理器进行管理此 ...
Linux systemd limits
Linux systemd limits limits 关于Centos 7 / RHEL 7 中的limits要了解以下几点: CentOS 7 / RHEL 7的系统中,使用Systemd替代了之 ...
Linux Systemd服务
Linux Systemd服务(2021.07.09) 文章目录 Linux Systemd服务(2021.07.09) 一.概述二.配置文件 2.1 Unit 2.2 Service 2.3 In ...
Linux中service文件详解
1. 什么是systemd service systemd service是一种以 .service 结尾的配置文件,是一个专用于 Linux 操作系统的系统与服务管理器.简单来说,用于后台以守护精灵 ...
linux Systemd详解
1.Systemd 简介 Systemd 是一系列工具的集合,其作用也远远不仅是启动操作系统,它还接管了后台服务.结束.状态查询,以及日志归档.设备管理.电源管理.定时任务等许多职责,并支持通过特定事 ...
总结：linux之Service
一.什么是.service文件? Linux中.service文件是某项服务对应的配置文件,可用于systemd管理和控制的服务的设置. 比如我们的firstrun.service文件: .servi ...

linux systemd.service说明

翻译

描述