![特定のサービスを特定のインターフェイスに依存させる方法は？ [コピー]](https://linux33.com/image/110160/%E7%89%B9%E5%AE%9A%E3%81%AE%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%92%E7%89%B9%E5%AE%9A%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%82%A4%E3%82%B9%E3%81%AB%E4%BE%9D%E5%AD%98%E3%81%95%E3%81%9B%E3%82%8B%E6%96%B9%E6%B3%95%E3%81%AF%EF%BC%9F%20%5B%E3%82%B3%E3%83%94%E3%83%BC%5D.png)
SystemDを使用して特定のサービスが特定のネットワークインターフェイスの開始に依存するようにするにはどうすればよいですか？
libvirtdたとえば、802.1ad結合インターフェイスがあり、他のインターフェイスを介してネットワークにアクセスできる場合でも、起動前にSAN / NASにアクセスするのを待つ必要があるとします。または、sshfsVPN接続に基づいて自動起動（および自動解除）したいマウントがあるとします。
ネットワークインタフェースへのきめ細かい依存関係を処理する慣用的な方法は何ですか？
現在、私はUbuntuとCentOS7でNetworkManagerを使用していますが、他のプラットフォームに適したネットワーク状態管理メカニズムも利用できます。
答え1
実際に確立された標準がないと思いますがsystemd。
ExecStart= のコマンドの前にそれぞれ実行される追加コマンドです。構文は、複数のコマンドラインが許可され、コマンドが順次実行されることを除いて、ExecStart =と同じです。
"-"プレフィックスなしでこれらのコマンドのいずれかが失敗すると、残りのコマンドは実行されず、デバイスは失敗したと見なされます。
サービスプロセスが終了、終了、またはタイムアウトしたときにサービスを再起動するかどうかを設定します。
on-failureに設定すると、プロセスがゼロ以外の終了コードで終了すると、信号（コアダンプを含むが上記の4つの信号は含まない）によって終了し、タスク（サービスの再ロードなど）がタイムアウトします。設定されたビューがトリガされると、ウォッチドッグがタイムアウトします。
コマンドがゼロ以外の終了コードを返した場合は失敗したと見なされるため、インターフェイスが動作していることを証明するように設定すると、ExecStartPreサービスにそれを要求させることができます。
いくつかの例：
ExecStartPre=/usr/bin/ping -c 1 ${SAN_IP}
ExecStartPre=/usr/sbin/iscsiadm -m session
個人的にはiscsiadmユースケースのバリエーションが好きです。 iscsi 接続が存在する場合、戻り値は 0 で、そうでなければ 21 が返されます (これによりサービスが失敗します)。このpingバリエーションはより広い範囲の目的で使用できますが、ほとんどの場合、ネットワークの状態を確認するには、より適切なコマンドを見つける必要があります。ssh他のホストのコンテンツをスキャンするように設定されたキーがある場合でも、この方法を試すことができます。
要点は、ExecStartPreどのコマンドでもサービスが失敗する可能性があることです。使用するコマンドが必要なときにゼロ以外の終了コードを返すことを確認してください。 （たとえば、cat空のファイルを入力すると0を返し、cat存在しないファイルを入力すると1を返します。）
少し考えて質問者の意見の後、私は言います。最高サービスの複雑な条件を定義する方法は、そのサービスが依存する別のサービスを作成することです。
新しいサービスを作成し、このコマンドを使用してステータスを確認しますExecStart。それを提供Restart=on-failure。次に元のサービスを作成しRequireますAfter。
上記で使用した例は、ExecStartPreサービスが正常に機能するように設定したい元の目的でわずかに歪んでいました。それでも適用可能で、知識はまだ役に立つので、そのままにしています。