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

时间:2016-03-16 18:23:28

标签: linux systemd

服务(比如bar.service)依赖于另一个服务(比如foo.service),如下所示

bar的服务文件:

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

如果重新启动foo.service(手动或由于错误),bar.service如何自动重启?

3 个答案:

答案 0 :(得分:28)

您可以使用event.target

PartOf

来自[Unit] After=foo.service Requires=foo.service PartOf=foo.service 手册页:

  

PartOf =

     

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

答案 1 :(得分:1)

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

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

BindsTo =

     

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

     

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

结合起来

答案 2 :(得分:1)

另一个解决方案可能是使用 ExecStartPost 选项在foo.service(重新)启动时重启bar.service(如果已执行):

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

额外的重新启动重新启动安装选项可确保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。