我有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.service
[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状态a.service显示失败为状态）。 现在有一个选项，以便b.service可以知道a.service失败，它应该停止/退出？
你想添加BindsTo=或者Requires=到你的[Unit]部分，如man systemd.unit所记录的man systemd.unit ：
需求=配置其他单元的需求依赖关系。 如果这个单位被激活，这里列出的单位也会被激活。 如果其他单位之一被取消激活或激活失败，则该单位将被停用。 该选项可以多次指定，也可以在一个选项中指定多个空格分隔的单位，在这种情况下，将创建所有列出名称的需求依赖关系。 请注意，需求相关性不会影响服务启动或停止的顺序。 这必须使用After =或Before =选项独立配置。 如果一个单元foo.service需要一个配置为Requires =的单元bar.service，并且没有配置使用After =或者Before =的顺序，那么如果foo.service被激活，那么这两个单元将同时启动并且没有任何延迟。 通常，为了在处理失败的服务时实现更健壮的系统，使用“要求=”而不是“要求=”是更好的选择。
BindsTo =配置需求依赖关系，风格与Requires =非常相似，但是除了这个行为之外，它还声明当任何列出的单位突然消失的时候，这个单位会停止。 如果某个服务自行终止，则设备可能会突然意外消失，设备将被拔出，或者在不涉及systemd的情况下卸载安装点。