问题
A service (say bar.service) is dependent on another service (say foo.service), like below
bar's service file:
[Unit]
After=foo.service
Requires=foo.service
...
If foo.service is restarted (either manually or due to a bug), how can bar.service be automatically restarted as well?
回答1:
You can use PartOf.
[Unit]
After=foo.service
Requires=foo.service
PartOf=foo.service
From the systemd.unit man page:
PartOf=
Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units.
回答2:
A another solution might be to use ExecStartPost option to restart the bar.service (if it´s executed) when foo.service has (re)started:
# foo.service
[Service]
ExecStartPost=/bin/systemctl try-restart bar.service
Restart=on-failure
RestartSec=30s
The additional Restart and RestartSec options ensure that foo.service will automatically restarted on crash and thus also bar.service.
A second extension my be to add same to bar.service and ensure that bar.service start after foo.service:
# bar.service
[Unit]
After=foo.service
[Service]
Restart=on-failure
RestartSec=30s
This should start both services automatically in case of a crash and bar.service will be restarted when foo.service restarts (due to an error or manually triggered).
回答3:
I think the needed option is BindsTo, it handles the misbehaviours too.
[Unit]
Requires=postgresql.service
After=postgresql.service
BindsTo=postgresql.service
BindsTo=
Configures requirement dependencies, very similar in style to Requires=. However, this dependency type is stronger: in addition to the effect of Requires= it declares that if the unit bound to is stopped, this unit will be stopped too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too. Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of a mount unit might be unmounted without involvement of the system and service manager.
When used in conjunction with After= on the same unit the behaviour of BindsTo= is even stronger. In this case, the unit bound to strictly has to be in active state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly enters inactive state, but also one that is bound to another unit that gets skipped due to a failed condition check (such as ConditionPathExists=, ConditionPathIsSymbolicLink=, … — see below) will be stopped, should it be running. Hence, in many cases it is best to combine BindsTo= with After=.
来源：https://stackoverflow.com/questions/36043964/how-to-restart-a-service-if-its-dependent-service-is-restarted