Systemctl依赖失败，停止依赖服务答案

【问题标题】：Systemctl dependency failure, stop dependent servicesSystemctl依赖失败，停止依赖服务
【发布时间】：2017-07-31 13:58:56
【问题描述】：

我有 2 个服务 a.service 和 b.service。 a.service 显示

[Unit]
Description=My service

[Service]
Type=forking
ExecStart=/bin/sh /home/admin/run.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target,

b.服务

[Unit]
Description=My service

[Service]
Type=forking
ExecStart=/bin/sh $HOME/theFolder/run.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

现在，当我启动 b.service 时，我确定 a.service 会启动。在运行时，突然有人弄乱了 /home/admin/run.sh 并且 systemd 无法启动 a.service （也 systemctl status a.service 显示为失败状态）。现在有一个选项可以让 b.service 知道 a.service 失败并且应该停止/退出？

【问题讨论】：

BindsTo=a.service

标签： linux service systemd watchdog systemctl

【解决方案1】：

您想将BindsTo= 或Requires= 添加到您的[Unit] 部分，如man systemd.unit 中所述：

需要= 配置对其他单元的需求依赖。如果这个单位被激活，这里列出的单位也会被激活。如果其他单位之一被停用或其启动失败，则该单位将被停用。可以多次指定此选项，也可以指定多个空格分隔的单位在一个选项中指定，在这种情况下，将为所有列出的名称创建需求依赖项。请注意，需求依赖性不会影响服务启动或停止的顺序。这必须使用 After= 或 Before= 选项独立配置。如果一个单元 foo.service 需要使用 Requires= 配置的单元 bar.service 并且没有使用 After= 配置的排序或 Before=，那么两个单元将同时启动并且它们之间没有任何延迟，如果 foo.service 被激活。通常，使用 Wants= 而不是 Requires= 是更好的选择，以便在处理失败的服务时实现更强大的系统。

BindsTo= 配置需求依赖，风格与 Requires= 非常相似，但除此之外行为，它还声明当列出的任何单位突然消失时，该单位将停止。如果服务自行终止，设备可能会突然、意外地消失，设备在没有 systemd 参与的情况下拔出或卸载挂载点。

【讨论】：