これは一般的なUpstartの質問ですが、特定のケースを使用させてください。
Centrifyは、NISからActiveDirectoryへのゲートウェイです。それが提供する認証サービスに依存するサービスの前にロードする必要があります。 autofs、cron、nisなど.
これは、他のサービスの依存関係を変更しようとする場合でも、達成するのが非常に難しいことが証明されています(とにかく行う必要があるとは思わない、可能な限り他のUpstartジョブに触れたくない) 。
提案?
Jamesの答えは、1対1の依存関係で機能します。 1対多の場合、つまりサービスB、C、およびDの前にサービスAを確実に開始するには、別のアプローチをとる必要があります。現在のポートマップスクリプトを参照して確認できますが、一般的なアプローチは次のとおりです。待機スクリプトを作成します。
シナリオ:サービスAをalways service-b、service-c、およびservice-dの前に実行します。
# service-a-wait
start on (starting service-b
or starting service-c
or starting service-d)
stop on (started service-a or stopped service-a)
# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB
# Needed to make starting the job successful despite being killed
normal exit 2
task
script
status service-a | grep -q "start/running" && exit 0
start service-a || true
# Waiting forever is ok.. upstart will kill this job when
# the service-a we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
これが平易な英語で意味することは、サービスb、c、またはdが開始したいというシグナルを受け取ったとき、サービスaが実行されるまで開始を待たなければならないということです。 service-a-waitジョブは、service-aが開始されるまで実行されるように設計されています。 service-a-waitが終了すると、サービスb、c、およびdを自由に実行して実行できます。
これにより、その逆依存関係のいずれかが開始を試みる前に、service-aが確実に稼働します。
注:この「start on ... or .. or ..」シナリオでは、「instance $ JOB」行が重要です。それ以外の場合、B、C、またはDのいずれかが最初に発射される場合にのみ、実際にブロックします。
(インスタンス化は正直なところより良い説明に値します。今のところ、それをしてください。)
解決策は、別の方向から問題にアプローチすることです。Centrifyの開始基準を満たすために、既存のサービスを新しいCentrifyサービスに依存させる必要はなく、新しいCentrifyサービスを既存のサービスに依存させる必要があります。
たとえば、Upstart構成ファイル/etc/init/centrify.conf
は次のようになります。
開始(cronの開始、autofsの開始、nisの開始)
これを英語に変換すると、次のように翻訳されます。
centrifyサービスを開始します直前 cron、autofs、またはnis start(どちらか早い方)のいずれか。
Cron、autofs、またはnisの開始順序は関係ありません。Upstartは、Centrifyが最初に開始するサービスよりも先に開始することを保証するため、これらのサービスのいずれかが開始する前にCentrifyが実行されます。
また、Upstartは、Centrifyが実行を開始するまで、開始する最初のサービスの開始をブロックすることに注意してください。
このような考え方に慣れると、非常にエレガントでシンプルになります。