一个服务（比如bar.service）依赖于另一个服务（比如说foo.service），就像下面这样
酒吧的服务档案：
[Unit] After=foo.service Requires=foo.service ... 如果foo.service重新启动（无论是手动还是由于错误），bar.service如何自动重新启动？
你可以使用PartOf 。
[Unit] After=foo.service Requires=foo.service PartOf=foo.service
从systemd.unit手册页：
PartOf =
配置与Requires =类似的依赖关系，但仅限于停止和重新启动单位。 当systemd停止或重新启动这里列出的单位时，动作传播到这个单位。 请注意，这是单向依赖关系 – 对此单位的更改不会影响列出的单位。
我认为所需的选择是BindsTo，它也处理不当行为。
[Unit] Requires=postgresql.service After=postgresql.service BindsTo=postgresql.service
BindsTo =
配置需求依赖关系，风格与Requires =非常相似。 然而，这种依赖类型更强大：除了Requires =的效果，它声明如果绑定到的单位被停止，那么这个单位也会被停止。 这意味着绑定到突然进入非活动状态的另一个单位的单位也将被停止。 出于不同的原因，单元可能会突然意外地进入非活动状态：服务单元的主进程可能会自行终止，设备单元的后备设备可能会被拔出，或者挂载单元的挂载点可能不经过系统和服务经理。
当与同一个单元上的After =结合使用时，BindsTo =的行为更加强烈。 在这种情况下，该单元必须处于激活状态的单元也处于激活状态。 这不仅意味着绑定到另一个单元的单元突然进入非活动状态，而且绑定到另一个由于条件检查失败而被跳过的单元（如ConditionPathExists =，ConditionPathIsSymbolicLink =，… – 见下面）停下来，它应该运行。 因此，在许多情况下，最好将BindsTo =和After =结合起来。