web-dev-qa-db-ja.com

同じsystemdサービスの「前」と「欲しい」ですか?

Systemdユニットファイルの この例 では:

# systemd-timesyncd.service
...

Before=time-sync.target sysinit.target shutdown.target
Conflicts=shutdown.target
Wants=time-sync.target

systemd-timesyncd.servicebeforeの前に開始する必要がありますtime-sync.target順序付けの依存関係 を定義します。

しかし、同時にsystemd-timesyncd.servicewantstime-sync.target。そう time-sync.targetです 要件依存

この関係の使用例は何ですか?なぜそれらは互いに競合していないのですか?

この二重関係の使用例は、「提供」関係に似ています。 systemd-timesyncdは時間同期サービスを提供するため、ユニットがtime-sync.targetに依存するすべての依存関係を満たします。 time-sync.targetより前に開始する必要があります。これは、時間同期に依存するすべてのサービスに必要であり、time-sync.targetが必要なためです。時間同期に依存するユニットは、systemd-timesyncdサービスとともに開始する必要があるためです。

誤解はあなたの「欲望」の解釈に由来すると思います。 systemdの「wants」関係は依存関係ではありません。systemd-timesyncdが機能するためにtime-syncは必要ありません。これは「開始」の関係です。構成ユニット(systemd-timesyncd.service)は、リストされたユニット(time-sync.target)も一緒に開始することを望んでいることを示しています。

参照 systemdでtime-sync.targetを提供するサービスはどれですか?

13
Stephen Kitt

このメカニズムの目的は、順序関係を作成できるようにすることですが、必要でない限り有効になりません

time-sync.targetは注文マイルストーンです。 「時刻同期」を提供するすべてのサービスは、Beforetime-sync.target、「時間同期」が有効になっている場合にのみターゲットが準備完了になるようにします。実行時に「時間同期」を有効にする必要があるすべてのサービスは、Aftertime-sync.target

後者もそのターゲットとのWants関係を持っている場合、常にalwaysになるため、常にターゲットになる整理されるもののセットに含まれる。

これは、実際には具体的な「時間同期」サービスがない場合、最適とは言えません。そして、systemdの人々の考えは、そのような順序付けがそのような場合に有効であってはならないということです。むしろ、サービスはtime-sync.targetはありませんでした。マイルストーンのない「自然な」位置である場合、それらの一部をより早く開始できます。

ソリューションはtime-sync.target実際にはそこにいない。時間同期が利用可能になった後に開始することを期待しているサービスでは必要ありません。したがって、それらだけのサービスが開始されている場合、それは順序付けられたもののセットには存在しません。 actual「時間同期」サービスが開始され、(クライアントサービスではなく)Wants関係。

ターゲットは必ずしもサービスのコレクションである必要はありません。また、マイルストーンを注文することもできます。

Systemdやその他の場所には、このような純粋なマイルストーンがかなりあります。 name-services noshツールセットのサービスバンドルコレクションのターゲットは、同様の純粋な注文マイルストーンです。

参考文献

  • ジョナサン・デ・ボイン・ポラール(2018)。 system-controlnoshガイド。ソフトウェア。
5
JdeBP

time-sync.targetはシステムのフラグの一種であるため、正しい時刻に依存するサービスは、systemd-timesyncd、ntpdなどに依存する必要はありません。

Beforeエントリーは、systemdにsystemd-timesyncdを開始し、次にtime-sync.targetを開始するように指示します(これは注文用です)。 Wantsは実際にフラグを設定するように指示します。

0
Uwe Ohse