如果重新啟動其依賴服務，如何重新啟動服務

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 =結合使用。