如果重新启动其依赖服务，如何重新启动服务

Question

服务（比如bar.service）依赖于另一个服务（比如foo.service），如下所示

酒吧的服务文件：

[Unit]
After=foo.service
Requires=foo.service
...

如果foo.service重新启动（手动或由于错误），bar.service如何自动重启？

Answer 1

您可以使用PartOf 。

[Unit]
After=foo.service
Requires=foo.service
PartOf=foo.service

从systemd.unit手册页：

PartOf =

配置类似于Requires =的依赖项，但仅限于停止和重新启动单元。 当systemd停止或重新启动此处列出的单元时，操作将传播到此单元。 请注意，这是单向依赖关系 - 对此单位的更改不会影响列出的单位。

Answer 2

另一种解决方案可能是使用ExecStartPost选项在foo.service（重新）启动时重新启动bar.service（如果已执行）：

# foo.service
[Service]
ExecStartPost=/bin/systemctl try-restart bar.service
Restart=on-failure
RestartSec=30s

额外的Restart和RestartSec选项可确保foo.service在崩溃时自动重启，因此也可以自动重启bar.service。

第二个扩展我可以添加到bar.service并确保bar.service在foo.service之后启动：

# bar.service
[Unit]
After=foo.service

[Service]
Restart=on-failure
RestartSec=30s

这应该在崩溃的情况下自动启动两个服务，并且当foo.service重启时（由于错误或手动触发）将重新启动bar.service。

Answer 3

我认为所需的选项是BindsTo，它也可以处理不当行为。

[Unit]
Requires=postgresql.service
After=postgresql.service
BindsTo=postgresql.service

BindsTo =

配置需求依赖项，风格与Requires =非常相似。 但是，这种依赖类型更强：除了Requires =的效果之外，它声明如果绑定的单位被停止，该单位也将被停止。 这意味着绑定到突然进入非活动状态的另一个单元的单元也将被停止。 由于不同的原因，单元可能会突然意外地进入非活动状态：服务单元的主进程可能会根据自己的选择终止，可能会拔出设备单元的后备设备，或者可能卸载安装单元的安装点而不涉及系统和服务经理。

当与After =在同一单位上使用时，BindsTo =的行为甚至更强。 在这种情况下，严格必须处于活动状态的单元也必须处于活动状态。 这不仅意味着一个单元绑定到另一个突然进入非活动状态的单元，而且还绑定到另一个单元，该单元由于条件检查失败而被跳过（例如ConditionPathExists =，ConditionPathIsSymbolicLink =，...... - 见下文）将是它应该停止运行。 因此，在许多情况下，最好将BindsTo =与After =结合使用。