systemd悪夢 - 起動時に開始され、必要に応じて再起動されるようにサービスを注文します。

手順についてはマニュアルページを確認してくださいsystemd.unit。以下に含まれていますが、説明するために最善を尽くします。

Requires強い依存性です。有効にすると、my.service次にリストされている項目Requires=も有効になります。後でリストされたデバイスの1Requires=つ明らかに止まるとmy.service止まります。いいえ、Before=またはをAfter=使用して順序my.serviceと後でリストされた単位を設定すると、Requires=同時に開始されます。

Wants弱い依存性です。起動すると、後でリストされたデバイスが起動Wants=します。my.serviceただし、リストされているデバイスに起動に問題がある場合、my.service起動は中断されません。

BindsToRequiresよりも依存性が強い。これは要件に似ていますが、何らかの理由でリストされているBindsTo=サービスmy.serviceも停止してから停止します。

AfterどちらBeforeも順序を指定するために使用されます。これはRequires、Wantsとは別の設定ですが、BindsToサービスの開始順序を指定するために一緒に使用できます。

PropagatesReloadToPropagatesReloadFrom複数のデバイスにまたがるリロードをキューに入れるために使用されます。my.service指定した場合、PropagatesReloadTo=docker.service再ロードするとmy.service再ロードされますdocker.service。my.service指定した場合、PropagatesReloadFrom=docker.service再ロードするとdocker.service再ロードされますmy.service。

Wants可能であれば、Requiresorを使用することを少しお勧めしますBindsTo。

WantsとRequiresサービスを重複しないでくださいBindsTo。指定するユニット・ファイルのサービス要件に適したものを決定して使用します。

docker.serviceおよび/またはManagement.serviceが再起動されるたびにmy.serviceも再起動する必要があります（dockerと管理の後）。

別のサービスが再起動したときに1つのサービスを再起動する場合は、代わりにPartOf=使用できますRequires。

PartOf =はRequires =と同様に依存関係を構成しますが、デバイスを停止して再起動することに制限されます。 systemdがここにリストされているデバイスを停止または再起動すると、ジョブはそのデバイスに伝播されます。これは一方向の依存関係です。このデバイスを変更しても、リストされているデバイスには影響しません。

my.serviceはdockerコンテナを起動するので、my.serviceを起動する前にdocker.serviceを起動したいと思います（docker.serviceは私のシステムで無効にすることができます）。

After=docker.service management.service次に起動するように設定my.serviceし、上記のように再起動するにはを使用します。再起動を伝播する必要がない場合は、おそらく、との間で決定します。しかし、不要で強力な依存関係を作成しないようにしてください。docker.servicemanagement.servicePartOf=docker.service management.serviceWantsRequiresBindsTo

それから

必要=
    他のユニットの要件依存関係を構成します。このデバイスがアクティブになると、ここにリストされているデバイスもアクティブになります。他のデバイスの1つがアクティブではなく、注文の依存関係が後で=の場合
    設定に失敗したデバイスは起動しません。また、After =を指定するかどうかにかかわらず、他のデバイスの1つが明示的に停止すると、このデバイスは停止します。このオプションは複数回指定できます。
    1つのオプションに複数のスペースで区切られた単位を指定できます。この場合、リストされているすべての名前に対して要件の依存関係が生成されます。要件の依存関係はサービスの順序には影響しません。
    開始または停止しました。これはAfter =またはBefore =オプションを使用して独立して設定する必要があります。 foo.service デバイスに bar.service デバイスが必要で、Requires= として設定され、順序が設定されていない場合
    After= または Before=, foo.service が有効な場合、両方のデバイスは遅延なく同時に起動します。目標を達成するには、Requires=の代わりにWants=を使用する方が良いことがよくあります。
    失敗したサービスを処理すると、システムはより強力になりました。

    この依存関係タイプは、このデバイスが実行されているときに他のデバイスを常にアクティブにする必要があるわけではありません。具体的には：条件チェックに失敗しました（例：ConditionPathExists =、
    ConditionPathIsSymbolicLink =、... - 以下を参照してください。Requires =依存関係を持つデバイスの起動操作が失敗することはありません。さらに、一部のデバイスタイプは独自に無効にすることができます（たとえば、サービスプロセスでは
    完全にシャットダウンしたり、ユーザーがデバイスを切り離した可能性があります）Requires =依存関係を持つデバイスには伝播されません。ユニットが絶対に表示されないようにするには、After= と共に BindsTo= 依存関係タイプを使用します。
    アクティブ、特定の他のデバイスもアクティブではありません（下記参照）。

欲しい=
    Requires= の弱いバージョンです。ハイブがすでに起動している場合は、このオプションにリストされているデバイスが起動します。ただし、リストされているデバイスを起動できない場合、またはトランザクションに追加できない場合、これは有効性には影響しません。
    完全な取引。これは、あるデバイスの起動を別のデバイスの起動に接続するための推奨方法です。

=前、=後
    両方の設定には、スペースで区切られた単位名のリストが必要です。ハイブ間の依存関係を注文します。デバイス foo.service に Before=bar.service 設定が含まれていて、両方のデバイスが起動した場合、
    foo.serviceの起動が完了するまでbar.serviceの起動が遅れます。この設定は、Requires =、Wants =、またはBindsTo =で構成される要件の依存関係とは無関係で直交です。これは
    一般的なパターンは、After =およびRequires =オプションにデバイス名を含めることです。この場合、リストされたデバイスは、これらのオプションで設定されたデバイスの前に起動されます。このオプションを使用すると、より多くを指定できます
    この場合、リストされたすべての名前に対してソート依存関係が複数回生成されます。 After= は Before= の逆数です。つまり、After =は、リストされているデバイスの起動が完了した後に構成されたデバイスが起動することを保証します。
    up、Before=はその逆を保証します。つまり、リストされたデバイスが起動する前に、設定されたデバイスが完全に起動します。シーケンシャル依存性を持つ 2 つのユニットが閉じられると、
    アプリケーションの起動順序。つまり、あるデバイスが別のデバイスにAfter =を設定した場合、両方のデバイスがシャットダウンすると、前者は後者の前に停止します。 2つのユニット間に順次依存関係がある場合、ユニットがある場合
    1つは終了すること、もう1つは最初に終了してからオンにすることです。この場合、順序の依存関係がAfter =かBefore =かは重要ではありません。どちらのどちらが閉じられているかは問題ではありません。
    終了するには、1つを終了してもう1つを開始します。すべての場合において、開始前に終了が命令されます。 2 つのデバイス間に逐次依存関係がない場合は、終了または開始されます。
    同時にソートは発生しません。デバイスの起動が完了するタイミングは、デバイスの種類によって異なります。最も重要なのは、サービスユニットの場合、起動が完了したと見なされることです。
    以前=/以降=設定されたすべての起動コマンドが呼び出され、失敗したか成功した起動を報告した場合。

=に縛る
    要件依存関係を構成します。スタイルはRequires =と非常によく似ています。しかし、このタイプの依存関係はより強力です。 Requires=の効果に加えて、バインドされたユニットが停止した場合、そのユニットは
    またブロックされました。つまり、突然無効になった他のデバイスにバインドされたデバイスも停止します。さまざまな理由により、デバイスが突然予期せず無効になる可能性があります。サービスの主なプロセス
    デバイスはそれ自体でシャットダウンすることができ、デバイスをサポートするデバイスのプラグを外すことができ、デバイスが取り付けられているマウントポイントをシステムおよびサービスマネージャの介入なしにマウント解除することができます。

    BindsTo =の動作は、同じセルでAfter =と一緒に使用するとより強力になります。この場合、厳密にバインドされたユニットをアクティブにする必要があり、このユニットもアクティブになります。これはない
    これは、他のデバイスにバインドされたデバイスが突然無効になったことを意味するだけでなく、条件検証に失敗したために他のデバイスにバインドされたデバイスをスキップしたことを意味します（例：ConditionPathExists =、
    ConditionPathIsSymbolicLink =、... - 以下を参照）が実行されると停止します。したがって、多くの場合、BindsTo =とAfter =を組み合わせることをお勧めします。

PropagatesReloadTo=, ReloadPropagatedFrom=
    デバイスの再ロード要求が伝播されるか、他のデバイスに対する再ロード要求が伝播される1つ以上のデバイスをスペースで区切ったリスト。リフレッシュをリクエストする
    さらに、デバイスは自動的にリロード要求をすべてのデバイスにキューに追加し、再ロード要求は両方の設定を介して伝播されます。