How to restart a service if its dependent service is restarted

Question

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?

Answer 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.

Answer 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).

Answer 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=.