<p>監視対象はすべてのプロセスを同時に開始します</p>

これが正しく行われない場合、スーパーバイザーを使用する意味がわかりません。

@mnaberezこれに未解決の問題がある場合は、リンクを投稿して、見つけられるようにする必要があります。

また、特定の順序でプロセスを開始する機能も必要です。

イベントベースのアプローチが機能する可能性があります。 たとえば、 [program:agent]と[program:client]がある場合、エージェントがstartedイベントを発行したときに、クライアントをサブスクライブして起動できます。 デフォルトでは、プログラムがどのイベントにもサブスクライブしていない場合、 supervisordの開始時にプログラムが開始されます。

+1

+1

+1

+1、この大きな問題。

+1

+1

+1

+1

+1

：+1：

+1

+1

+1

持つ必要があります

スーパーバイザーに依存関係はありますか？ そうでない場合は、なぜですか？

+1

+1

+1

+1

+1

知覚されるプレッシャーを増したくはありませんが、まったく同じ機能（プロセスの依存関係）で+1されます。 :-)

これは非常に便利で、睡眠のような醜いハックが少ないことを意味します

+1

+1

+1。 たぶん、プロセスのロードを同期化するオプションです。

：+1：

+1

：+1：

+1

+1

誰かがこれについて他の実装の考えを持っていますか？ 他の誰も気にしないように見えるので、私はそれを実行することを検討しています。

+1

@tomislackerええと、私見の最善の解決策は、依存関係ソルバーをPuppetにすることです。 よくわかる場合は、DFSを使用した最も単純なトポロジカルソートで十分です。 次に、「requiresstarted」フィールド（または「waitforstarted」、または同様のもの）を追加します。 ちなみに、この問題は修正されます。

（編集）まあ、 A -> B -> C （ AはBなどに依存します）を持っているときに誰かがBを止めようとするとどうなるかわかりません。 Aも停止する必要がありますか？ ええと…/ depends /…

：+1：

誰もがこれを少し異なる方法で行う必要がある/したいように見えるので、少し異なるタックはどうですか？ 構成ディレクティブで直接依存関係を表現しようとする代わりに、代わりに「ヘルパー」スクリプトのディレクティブと、 @ kgadekが指摘したように要件が異なる2〜3の一般的なユースケースに適合するいくつかのヘルパーの例を追加してはどうでしょうか。

これが私が何を意味するかを示す良い例です：
http://www.serfdom.io/docs/recipes/event-handler-router.html

この種のことをbashで簡単に行うためのいくつかのものがありますが、
https://github.com/progrium/pluginhook

そして、あなたは確かに「Pythonでそれを書きたいと思った」（または管理者が選択した他の言語）の素晴らしさを軽視することはできません
https://github.com/garethr/serf-master

これは、スーパーバイザー自体に多くの開発者時間を費やすことなく、すべての人にとって合理的な勝利になると私には思えます。

おい、

農奴モデルは非常に有望に見えます。 ハンドラーを1つだけではなく、スクリプトのコレクションを用意するのが適切だと思われます（たとえば、開始する前に2つのdepsをチェックする）

したがって、ハンドラーを定義して、process / group：xが "can_be_started"であるかどうかを確認し、すべてのスクリプトが0を返す場合は、すべて問題ありません。 聞こえますか？

私見これは「優先順位」を時代遅れにします、私は間違っていますか？

私のニーズでは、スーパーバイザデーモンが起動してからプロセスごとに遅延を設定するだけで十分です。

このためのさらに別の+1

+1。 プロセスごとの遅延で十分です。

私はこれを少し回避することができました。 速くて汚い。

# Deal with updating our repositories.
supervisorctl start source-code-deploy

# Check for the oneshot process to complete.
while ! supervisorctl status source-code-deploy | grep -q 'EXITED'; do sleep 1; done
# Wait for the while loop to break out signalling success.

# Start the late boot process, now that the deployment is complete.
supervisorctl start system-boot-late

# Check for the oneshot process to complete.
while ! supervisorctl status system-boot-late | grep -q 'EXITED'; do sleep 1; done
# And now we should become EXITED to supervisord and any other tasks relying on the above.

+1

+1

こんにちは、
今後数週間でこれを試してみたいのですが、他の誰かが取り組んでいる場合はお知らせください。

まったく同時に多くのプロセスを開始しようとすると、マシンが限界に達し、場合によってはそれを超える傾向があります。

「startdelay」のようなパラメータを持つことは、特にいくつかのプロセスが最初に起動するときに大量のリソースを使用する傾向があるため、非常に便利です。リソースはしばらくすると解放されます。

残念ながら、そのような機能を実装する方法はかなりあり、最適な機能を見つけるには時間がかかる可能性があります。

@vladfrおそらく私たちはこれについて協力することができます。

私の最初の「汚い」亀裂：
https://github.com/liutec/supervisor/commit/eab7cc1e04ad49768593183e8134298604459827
（私は本当にこのように睡眠を使わなければならないのが好きではありません。）

こんにちは@ liutec 、 @ kamilionがフックモデルについて言っていることを上で見てください-これはカスタムチェックを実装するのに便利であり、単純なケースでは単にスリープするために使用できると思います。
サブプロセスでフックスクリプトを実行すると、必要なだけスリープできます。

私の状況では、目標は、スーパーバイザーに約240の異なるプログラムを管理させることであり、そのうちのいくつかは複数のインスタンスを必要とする場合があります。

開始遅延は、プログラムが初めて開始されるときにのみ役立ちます。これは、すべてのプログラムがまったく同時に開始されるという、他の方法では起こりそうもない状況を回避するためです。

ほとんどのプログラムはコンシューマーであり、シャットダウンしてスーパーバイザーによって再起動されるまでの短時間しか実行されません。この場合、開始遅延があると効果がありません。

@kamilionのソリューションと@mnaberez （autostart autorestart）によって提供されるソリューションの両方を検討しましたが、残念ながら、簡単に構成できる「startdelay」を実際に生成するものはありません。

+1監督者が素晴らしい「シーケンス制御」を持っていた場合、KafkaはZookeeperなどに依存し、監督者は私たちが望むように使用できなくなります。

+1

私はsupervisordを使用してエキゾチックなqemuインスタンスの束を開始しています（コンパイラーコース用）。これらのインスタンスの一部は自動的に起動しますが、一度に開始するとかなり長い時間がかかります。 単純な「startdelay」は問題なく機能します。このプロセスを開始した後、リスト内の次のプロセスに進む前に、指定された秒数だけスリープします。 これらをどのように注文するかは正確にはわかりませんが（priorityキーワードは、作成されたpidからわかる限り厳密には注文されていないようです）、それが何であれ、各プロセスの後に数秒間遅延する可能性があります私の場合、全体の助けになるでしょう。 だから：+1：確かに。 実際には2回。 :-)

startdelayオプションは非常に便利だと思います。 AMQPサーバーと一部のコンシューマーを管理するスーパーバイザーがいます。 一部のコンシューマーは、開始する前にスリープを実装し、一部のコンシューマーは、接続/エラー/スリープシーケンスの試行をループします（さまざまな実装）。 AMQPサーバーを起動する必要がある最大時間を知っているので、コンシューマーにstartdelayオプションを追加すると、これらの醜いハッキングを回避できます。

これは多くの状況で非常に役立つと思います。

コードを確認したところ、BCの問題は見られません。また、デフォルト値を使用した場合のスーパーバイザーの動作も同じです。
これがマージされるのが待ちきれません。

依存関係のサポートのための+1

+1

+1

+1

+1

+10;）

+1。

startsecsはここでは関係ないと思うので、この問題の名前を変更する必要があります。 OPは、プロセスを開始する前に待つのが遅れていると考えて、 startsecsが何であるかを誤って解釈した可能性があるように感じます。

startsecs

起動後にプログラムが実行を継続するために必要な合計秒数
開始は成功しました。 プログラムが起動した後、この数秒間起動しない場合
開始され、「予期された」終了コード（exitcodesを参照）で終了した場合でも、起動は>になります。
失敗と見なされました。 0に設定すると、プログラムを実行し続ける必要がないことを示します。
特定の時間。

+1

+1

重要な機能
+1も

+1

+1

+1

+1

+1

私が使用する簡単な回避策：

[program:uwsgi]
command=bash -c 'sleep 5 && uwsgi /etc/uwsgi.ini'

+1

+1

この問題をより責任ある方法で解決する方法について誰かが考えていますか？ プロセスの_ "online" _状態を検証するために呼び出すことができるコマンドがある場合はどうなりますか？ そのような：

[program:myapp]
command=/usr/local/bin/myapp-microservice
checkcommand=curl -s http://localhost:54321/v1/_ping
checkfreq=1
checktimeout=3
startsecs=5

上記の例は、次のことを意味します。

1. commandは通常どおり実行されます
2. checkcommandは、上記の呼び出し後、おそらくchecktimeoutと組み合わせて、 startsecsが中止されるか、コマンドが0を返すまで、 checkfreq秒ごとに実行されます。 0 。

_例： checkcommandへの各呼び出しに<= 3秒かかる場合、 checkfreq=1 、 checktimeout=3 、およびstartsecs=5 ; checkcommandは+ 1.0秒実行され、失敗した場合は+ 5.0秒で終了し、2回目のcheckcommand呼び出しの終了時にサービスが失敗したことを示します。_

1. checkcommand 0の終了ステータスを返す場合、サービスはオンラインであると見なされます。
2. checkcommandがstartsecs $の後に$ 0の終了ステータスを返さない場合、またはcheckcommand >=checktimeout秒間ハングする場合、サービスの開始は失敗と見なされ、_ "通常の" _ロジックはすでに配置されていると見なされます。 _（サービスを失敗としてマークする、同じログコンテンツを出力するなど...）_

問題を解決したいように思えますが、この問題では十分に説明していません。 実を結ばない答えは、優先度の高いすべてのサービスの_max（startsecs）_まで、優先度の異なるサービスが呼び出されないようにすることです。 しかし、途中で検証するのではなく、意図した結果を大まかに振り付けできることを期待して、それだけを求めているのではないでしょうか。

：+1：

@tomislacker完全な検証が100％の場合であっても、多くの用途でルーズコレオグラフィーは許容できる90％のケースだと思います。

真の依存関係管理に入ると、実際のinitのように見え始め、さらに複雑な問題になり始めます。 しかし、確かに手に負えない果物のシナリオがあります。

：+1：

+1これが必要です

@tomislackerこれは良い考えであり、現在の構成ファイルが必要なだけなので使いやすいです。
しかし、実際の依存関係をどのように処理しますか？ my_programがPostgresに依存している場合、checkcommandで数回チェックし、起動することを望みますか？

依存関係を表現するには、実際のコマンドの前にcheckcommandを実行したいと思います。

@tomislackerプログラム間に単純な依存関係があることを望みます

[program:A]
command=/usr/local/bin/A

[program:C]
command=/usr/local/bin/C
dependson=A

そして、プログラムがより複雑な条件をチェックするかどうかをユーザーに決定させます。 例： Aが正しく実行されていることを確認するための高度なチェックを実行する[program:B]を挿入できます。 そうでなければ失敗します。 つまり、 Aが始まります。 BはA $に依存するため、スーパーバイザーがAがRUNNINGであると見なした場合にのみ開始されます。 Bが開始すると、分析が実行され、 Aが正しく実行されていない場合は失敗します。 Cは、 Bが実行されたとき（または正常に実行されたとき）にのみ開始されます。

私の提案は、チェックの数、それらのチェックのタイミング、いつあきらめるかなど、あなたが提案する追加の機能をカバーしていません。 しかし、 Bのようなプログラムを簡単に定義できるように、SupervisorにいくつかのCronのような機能を与えることも提唱しています。

[program:A]
command=/usr/local/bin/A

[program:B]
command=curl -s http://localhost:54321/v1/_ping
dependson=A
startretries=3
restartintervalsec=5

[program:C]
command=/usr/local/bin/C
dependson=B

また、SupervisorにCronのような機能をいくつか提供することを推奨します

＃635の回答をご覧ください。 これは過去にスーパーバイザー開発者によって詳細に検討されており、cronのような機能はこのプロジェクトの範囲外であると判断されました。 ごめん。

：+1：実行可能な方法で順次実行を提供する方法。

startuppriorityのようなものを使用することは、このIMOを実行するための優れた堅牢な方法です。

+1

最初の例の@ klahnakoski 、Aに依存するCは、スーパーバイザーがAの準備ができていることを知る必要があることを意味します。 今のところ、それはそれが開始されたことを知っているだけです。

@vladfrはい、あなたは正しいです。 そのため、Aの準備ができているかどうかを判断するためのより高度なチェックであるBも提案しました。 理想的には、Bは定期的にトリガーされ、Aの準備ができていない場合は失敗します。

+1

+1

+1 ?? これは2012年5月からです。スーパーバイザーが依存関係を持つことは決してないと思います。

誰かが依存関係管理の代替案を提案できますか？

+1、これは物事をはるかにエレガントにするでしょう

+1

+1

+1

+1、今のところsystemdユニットを使用して、これが3年後に実行できなくなるのは悲しいことです

 .----------------.  .----------------. 
| .--------------. || .--------------. |
| |      _       | || |     __       | |
| |     | |      | || |    /  |      | |
| |  ___| |___   | || |    `| |      | |
| | |___   ___|  | || |     | |      | |
| |     | |      | || |    _| |_     | |
| |     |_|      | || |   |_____|    | |
| |              | || |              | |
| '--------------' || '--------------' |
 '----------------'  '----------------' 

または、追加してください。

+1

+1

+1

+1

+1

+10086

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

うわー、本当に？ どうして誰もこれを気にしないのですか？ 「依存関係」はここでは良い考えのように聞こえます。 私が言及した回避策は、スクリプトをプログラムとして起動することでした。この場合、スクリプトは依存関係をチェックし、それ以外の場合は爆破します。 爆撃により、スクリプトは後で再起動されます。

+1

+1

+1

+1

+1。 2016年今...

+1

+1

+1

+1

皆さん、昔ながらの+1コメントの代わりに、元のトピックの「いいね」ボタンを使用してください:)これがGithubの目的です。

ありがとう！

皆さん、昔ながらの+1コメントの代わりに、元のトピックの「いいね」ボタンを使用してください:)これがGithubの目的です。

+1：trollface：

私の投票は、依存関係を表現し、監視対象が依存関係を開始する前に開始するのを待つ、単純なdependsonスタイルのシステムに投票します。 監視対象者がシャットダウン時に正しい順序でそれらを停止することもできれば素晴らしいと思います。 ただし、1つのサービスを手動で停止する場合、そのシナリオで監視対象が扶養家族を停止しようとする必要はないと思います。 誰かが空想を得たいと思ったら、彼らは扶養家族をシャットダウンするのを止めるために旗を追加することができます。

起動やシャットダウンなど、無人の状況での注文について賢く監視する必要があります。 停止や開始など、トリガーする特定のコマンドに応答してスマートである必要はありません。

こんにちは@mnaberez 、私はプロセス依存機能のステータスが何であるか疑問に思いました。 2012年にやることリストに載っていたとおっしゃいましたか？ これはまだ来ていますか？

プロセス依存機能のステータスはどうなのか気になりました。 2012年にやることリストに載っていたとおっしゃいましたか？ これはまだ来ていますか？

これはやることリスト（ TODO.txt ）にあり、この問題はまだ解決されていません。 現在、開発者が取り組んでいるとは思いません。

+1

これをスーパーバイザーに実装するのは本当に難しいですか？ この機能を提供するスーパーバイザーと同様のツールが他にあるかどうか疑問に思いましたか？

+1

+1

+1

+1

+1

更新はありますか？ この機能を利用できるようになると、アプリケーションの監督者にとって大きなメリットになります。

重労働のsystemd（upstart、sysv-init、...）ソリューションではなく、supervisordが主に軽量のinitマネージャーとして使用されていると思いますが、systemdがサービス開始の依存関係を非常にうまく管理しており、この問題が報告されて以来、supervisordにはまだそのような機能がありません2012年

ここで一部の開発者が次のような単純な依存関係を実装できないのはなぜですか？ このプロジェクトはメンテナの外にありますか

https://fedoramagazine.org/systemd-unit-dependencies-and-order/

Wants=sshd-keygen.service
After=network.target sshd-keygen.service

：+1：

皆さんこんにちは！

ようやく時間があり、これを試してみました。 これは、[program]と[group]の両方の構成オプションとして「dependson」を実装します。 他のプログラムおよびグループを依存関係として指定することができ、スーパーバイザーはそれらがプログラムの前に開始されることを確認します。

設定例：

[program:a]
command=a

[program:monitord]
command = ./monitord.sh
dependson=a
startsecs=5

[group:monitoring]
programs=c1,c2
dependson=monitord,a

[program:c1]
command = bash c1.sh
dependson=anotherprogram ; this doesn't matter because c1 is part of a group
autorestart=true

[program:c2]
command = bash c2.sh
autorestart=true

この構成により、次の開始順序が保証されます。

1. a
2. 監視
3. c1とc2を開始する監視グループ

program： c1dependson = anotherprogramに注意してください
c1はグループの一部であるため、その依存値はグループ値によってオーバーライドされます。 私の見解では、グループのメンバーは同じものに依存する必要があります。
ここで何か考えはありますか？

変更点を確認し、ブランチ「dependson_122」をチェックアウトして遊んでください。 やるべきことはまだありますが（循環デップ、フィニッシュテストなど）、最初にフィードバックが必要です！

https://github.com/Supervisor/supervisor/compare/master...vladfr：dependson_122？expand = 1

前もって感謝します。

誤って作成してごめんなさい＃776

https://github.com/Supervisor/supervisor/issues/122#issuecomment -227241447で参照されているsystemdセマンティクスを要約すると、次のようになります。

• Requires=このディレクティブは、このユニットが本質的に依存しているユニットを一覧表示します。 現在のユニットがアクティブ化されている場合、ここにリストされているユニットも正常にアクティブ化されている必要があります。そうでない場合、このユニットは失敗します。 これらのユニットは、デフォルトで現在のユニットと並行して開始されます。
• Wants=このディレクティブはRequires =に似ていますが、それほど厳密ではありません。 Systemdは、このユニットがアクティブ化されると、ここにリストされているユニットを起動しようとします。 これらのユニットが見つからないか、起動に失敗した場合、現在のユニットは引き続き機能します。 これは、ほとんどの依存関係を構成するための推奨される方法です。 繰り返しますが、これは、他のディレクティブによって変更されない限り、並列アクティブ化を意味します。
• BindsTo=このディレクティブはRequires =に似ていますが、関連付けられたユニットが終了したときに現在のユニットを停止させます。
• Before=このディレクティブにリストされているユニットは、同時にアクティブ化された場合、現在のユニットが開始済みとしてマークされるまで開始されません。 これは依存関係を意味するものではなく、必要に応じて上記のディレクティブの1つと組み合わせて使用​​する必要があります。
• After=このディレクティブにリストされているユニットは、現在のユニットを開始する前に開始されます。 これは依存関係を意味するものではなく、必要に応じて上記のディレクティブを介して確立する必要があります。
• Conflicts=これは、現在のユニットと同時に実行できないユニットを一覧表示するために使用できます。 この関係でユニットを起動すると、他のユニットが停止します。

https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files#unit-section-directivesから

このコマンドのサブセットは非常に強力であり、これらのディレクティブのいずれかを実装するために必要な整形式の依存関係ツリー+イベント生成により、残りのコマンドが非常に簡単になると強く思います。

@vladfr （https://github.com/Supervisor/supervisor/issues/122#issuecomment-228416456）

c1はグループの一部であるため、その依存値はグループ値によってオーバーライドされます。 私の見解では、グループのメンバーは同じものに依存する必要があります。
ここで何か考えはありますか？

より明確なセマンティクスは、依存関係を結合することだと思います。

これは、グループ全体がいくつかのプロセスに依存しているが、追加のプロセスに依存している可能性のあるメンバーがある場合に役立ちます。たとえば、1つのコンポーネントがデータベースサーバーと対話しているが、他のコンポーネントは静的ファイルの提供。

この場合、グループの多くのメンバーは、追加のプロセスに依存する1人のメンバーよりも早く開始される可能性があります。

+1

+1、昔ながらの方法：smile：

+1 plz

これをチェックして：
https://mmonit.com/monit/documentation/monit.html#SERVICE-DEPENDENCIES

これがマージされない論理的な理由はありますか？！ この機能をリクエストしてから4年が経ち、何十人もの人々が...私もその1人です。 これはイライラします。

こんにちは！ うわー、人々はこれに本当に興味を持っています。

@psigenこれが遅れてすみません。 グループのdepsをマージすると、構成が明確になりますが、機能的には良くなりません。 スーパーバイザーグループの実装方法により、オールオアナッシングを開始する必要があります。

言い換えれば、これは起こりません。「この場合、グループの多くのメンバーは、追加のプロセスに依存する1人のメンバーよりも早く開始される可能性があります。」 --b / cグループの一部のメンバーだけを開始することはできません。

ただし、どのサービスが実際の依存関係を持っているかを構成から非常に明確にするため、マージには反対しません。

来週は、これを実装し、テストを追加し、ドキュメントを書き直すために時間を費やします。 モニットのページは本当に良さそうです。レビューをして、ぶら下がっている果物があるかどうかを確認します。

一般的なアプローチに関する他のコメントはありますか？ @rrei今日はこれを利用できる人が多いので、実際のP​​Rを提出する前に、そのまま利用できるかどうかを知りたいと思います。

ありがとう！

@vladfrなるほど、それは大丈夫です。結局のところ、これは単なる最適化です。 フィードバックをお寄せいただきありがとうございます。

依存関係を結合すると、依存関係を追跡し、グループレベルで情報が重複しないようにすることが明確になると思います（つまり、メンバーが追加または削除されるたびにグループの依存関係を再評価する必要がありません）。

全体として、 DEPENDSディレクティブが1つしかない場合は、 monitスタイルのセマンティクスが最も適切であるように見えます（ supervisordの実行状態に適切に変換され、ディレクティブが参照できるようにします）依存関係としてメンバーとグループの両方に）：

https://mmonit.com/monit/documentation/monit.html#SERVICE -DEPENDENCIES

依存ステートメントの構文は次のとおりです。

service [、service [、...]]に依存します
serviceは、.monitrcファイルで使用されるチェックサービスエントリ名です。たとえば、apacheやdatafsなどです。

任意のタイプのサービス名を複数追加したり、エントリで複数の依存ステートメントを使用したりできます。

依存ステートメントで指定されたサービスは、停止/開始/監視/監視解除操作中にチェックされます。

サービスが停止または監視されていない場合、サービスはそれ自体に依存するすべてのサービスを停止/監視解除します。

サービスが開始されると、このサービスが依存するすべてのサービスが、このサービスを開始する前に開始されます。 一部のサービスの開始に失敗した場合、前提条件のあるサービスは開始されませんが、サービスが開始される必要があることを記憶し、次のサイクルを再試行します。

サービスが再起動されると、最初にそのサービスに依存するアクティブなサービスがすべて停止され、サービスが開始された後、再起動前にアクティブだったすべての依存するサービスが再開されます。

より複雑なsystemdセマンティクスは、さらに幅広いユースケースのセットをカバーし、ある時点でおそらく望ましいでしょうが、明らかにより複雑であり、スーパーバイザーが現在使用している内部状態に適合しない場合があります。

わかりました、@ psigenに感謝します！ 「依存」のシンプルなアプローチを終えます。
循環深度検出とドキュメントを追加しました。 テストを終了する必要があります。それだけです。
この機能は、グループdeps、[fcgi-process]、およびsupervisorctlで期待どおりに機能します。

ここでは、停止/再起動は手動で行う必要があることが提案されています。つまり、 dependsonは開始のみの制限として適用されます。 つまり、これが現在起こっていることです。 dependsonのプログラムが実行された後、それは独立しています。AがBに依存している場合、Bが終了してもAは停止しません。 これはドキュメントに記載されています。

ここにいくつかの議論のポイントがあります、フィードバックを歓迎します。

1. Supervisorctl：startはdepsを尊重します。 RPC呼び出しのオーバーライドを追加する必要があると思いますか？ process.spawnは、depsチェックをスキップする引数を受け取る可能性があります。 これは、[supervisorctl]セクションの構成にすることができます。 これを[監視対象]セクションに含めることもできます。
2. depが満たされていないためにプログラムを開始できない場合はいつでも、イベントをトリガーしますか？
3. これは、満たされていないdepに対するWARNメッセージの例です。 これは警告として大丈夫ですか？ ちょっとスパムなので、デバッグと見なすことができます。このメッセージは予期されたものです。

2016-08-08 19:21:00,419 WARN process 'tom' cannot start - group 'cats' depends on processes which are not started yet: ['mouse', 'night']

それで、 @ mnaberezは、これまでのところ、これらすべてがあなたにどのように見えていますか？

それで、 @ mnaberezは、これまでのところ、これらすべてがあなたにどのように見えていますか？

私はこれのどれも見ていません。 私の最初のフィードバックは、ある種の依存関係メカニズムを追加する場合、サポートの負担にならないように、ユーザーからの適切なフィードバックが必要になるというものです。 supervisorctl startのようなコマンドをブロックする場合、 supervisorctlが適切なメッセージを出力できるように、その情報をRPCコンシューマーに表示する必要があると思います。 これは、新しいプロセス状態またはRPC応答コードを意味する場合があります。 サポートチケットに答えた私の経験では、ほとんどのユーザーはメインログを必要以上に読んでいません。 依存関係コードがsupervisorctlコマンドをブロックする場合、その情報はsupervisorctlに表示される必要があります。

@mnaberezありがとうございます、考えさせていただきます！ 現在、プロセスはエラー状態（異常終了）に直接移行します。

記録としては、これは約18か月間個人的なことであるため、マージを検討する場合はボーナスになります。 いずれにせよ、4.0の候補のように聞こえます。

+1

+1

+1

@vladfr監視対象ブランチでは、「dependson」をクラスGroupProcessConfigのメンバーに設定する方が適切だと思います。 'rpcinterface.py'で 'removeGroup（）'を繰り返し呼び出す方が簡単だからです。

とても熱狂的です〜

ええ、私はある時点でそれを持っていたと思いますが、それを可能にするためにそれを変更しました
グループレベルでのdepsのマージ。 私はまだrpcを見ていませんが、見なければなりません、
提案ありがとうございます！

2016年8月28日、日曜日の15： [email protected]は次のように書いています。

とても熱狂的です〜

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Supervisor/supervisor/issues/122#issuecomment -242971739、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAM-h4JlTLaoxoMLEJRkNLBr_ZoOOmZzks5qkXy0gaJpZM4AAzaa
。

@vladfr Supervisorctlコマンドラインで入力したコマンドは、rpcのクラス関数への「関数呼び出し」に転送されます。 そして、rpcは最終的に 'supervisord.py'のクラススーパーバイザーのメンバー関数を呼び出します。

ユーザーが多すぎ、開発者が少なすぎます。 orz

@FAKERINHEARTこれは私が見た中で最も素晴らしいものです。 この状況は、この機能要求が本当に必要であると私に思わせます。 または、別の方法では、ソースコードを変更するのが難しすぎるということです。 ははは、本当に私を超越します、結局これは2年の問題です。

@FAKERINHEARTスーパーバイザー機能の一部、特にスーパーバイザーWebマネージャーページが必要なため、golangを使用して別のスーパーバイザーを作成しようとしました。 まだ進行中https://github.com/codeskyblue/gosuv

+1

+1

+1

編集：私は現在、サービスの順序付け/依存関係をサポートするシャペロンを使用しています。

プログラム間の依存関係を満たすために「スーパーバイザー」をカスタマイズしようとしました。これは、 vladfrによって提供されるコードに部分的に基づいています。 しかし、「スーパーバイザー」の元のバージョンのソースコードを読んだとき、「スーパーバイザー」のアーキテクチャーには優れていないものがあると思います。 'supervisor'のサブプログラムconfigの基本単位は、そのconfig-keyが 'program'（同種グループ）であるか 'group'（構成ファイル内の異種グループ）。
また、「supervisord」クラスオブジェクトとその遷移ループでは、前述の「configグループ」（processGroupconfig）から生成された「サブプロセスグループの配列」（process_groups）に基づいています。 「configgroup」ユニットは非常に大きいので、「superviosr」がそれらを管理するのに利点はないと思います。 さらに、この機能が将来計画に含まれる場合、サブプログラム間の依存関係を実現することはより困難になります。
サブプログラムの基本単位は「configprogram」（「processProgramconfig」と呼ばれることもあります）であり、「config group」（processGroupconfig）はそれらをまとめるためにのみ使用される方がよいと思います。

+100

私は本当にこれが必要でした、そしてイベントリスナーはそれほど難しく聞こえなかったので私はそれを書きました。 みんなの問題を解決するわけではなく、依存関係もありません。スタートアップを注文するだけです。
https://pypi.python.org/pypi/ordered-startup-supervisord/

+1..。

@FAKERINHEART返信が遅れたことをお詫びします。 私はあなたがスポットにいると思います-re：あなたが最後のコメントで説明したこと

'supervisor'のサブプログラムconfigの基本単位は、そのconfig-keyが 'program'（同種グループ）であるか 'group'（異種グループ）にマージされているかに関係なく、 'config group'（processGroupconfig）に転送されます。構成ファイル内。

それがまさに問題であり、このタスクが単純ではない理由です。
ここで改善または別の解決策を見つけましたか？ 私はそれについてもっとチャットしたいのですが、私を襲ってください。

+1

+1

+1

+1

+1

+1

+1

+1

+1

興味のある方のために、 https：//github.com/julien6387/supvisorsで、デプロイメントファイルの「start_sequence」プロセスルールを使用してこの機能に対処しました。

Supvisorsは分散アプリケーション用に設計されていますが、「山を移動できる場合は、モグラヒルを移動できます」。
単一のSupervisorインスタンスで動作します。

+1

+1

+1

+1

+1

+1

https://github.com/FAKERINHEART/supervisor
Introduction.txtを参照し、ブランチdev-3.3.1-sr1を使用してください。
@vladfrによって提案されたコードに部分的に基づいている、スーパーバイザーのグループ（プログラム）間の依存関係機能を備えたこのブランチがあります。
バグを見つけたら、時間内に教えてください。

+1

+1

この問題は2012年から公開されていますが、誰かが所有権を持っていますか？ これは多くのユーザーにとって明らかに重要です。 監督者の貢献者の間でコンセンサスはありますか？

+1

+1

+1

スーパーバイザープロジェクトの誰かがこれの所有権を取得するか、これが対処されない理由でチケットを閉じる必要があります。たとえば、スーパーバイザーはエラー状態で再起動を再試行できるため、対処する必要はありません。 （私のために働いた解決策）。

この号は2012年から発行されており、この期間チケットが開いたままになるのはちょっとばかげています。

+1..。

+1

+1

+1

参考：「+ 1」とだけ言って問題に返信すると、その問題に登録しているすべての人に通知が送信されます。 代わりに👍絵文字を使用して、問題の最初のコメントに反応することができます。

@AlecBenzer

参考：「+ 1」とだけ言って問題に返信すると、その問題に登録しているすべての人に通知が送信されます。

でもそれがポイントですね。 私はこの号を購読していますが、他の人が興味を持っているのを見てとても興味があります。 この問題は5年以上前のものです。 開発者に実際にpingを送信して、人々がまだ興味を持っていることを穏やかに思い出させるのは良いことです。 購読している人にとっては、その人だけでなく、気にかけている人もいることを確認するのも良いことです;）

参考：スレッドの右側に[登録解除]ボタンがあります。このスレッドからの通知を受け取りたくない場合は、これで問題ありません。このボタンを使用してオプトアウトできます。

特定の順序でプロセスを開始することが重要な要件であることを確認できます。 申し訳ありませんが、先に確認できませんでした。 今すぐ実装されますか？

この問題に対する私の解決策を共有すると、あなたのマイレージは変わるかもしれません。 これが修正されるのを待っている間、私はこの機能に依存しているインフラストラクチャのほとんどの部分をDocker / Kubernetesに移行しました。 さまざまなDockerオーケストレーションフレームワーク（docker-compose、swarm、Kubernetesなど）には、通常、起動順序を制御するメカニズムがあります（多くの場合、独自の課題があります）。 したがって、これが修正されるのを待っている場合は、単純なdocker-composeプロジェクトを試して、この問題に対する代替アプローチが提供されるかどうかを確認するための言い訳として使用してください。 これは、これが修正されるのを待っているユーザーのごく一部にのみ適用される可能性があることを認識しています。

皆さんこんにちは

依存サービスによって指定された順序でサービスを開始するためのサポートを備えたイベントプラグインを実装しました。
この例を見てください。

https://github.com/bendikro/supervisord-dependent-startup

@bendikroのすばらしいプラグインの代わりに、Dockerコミュニティのwait-for-it.shスクリプトを使用することもできます。 複雑な自動化システムで管理している場合は、セットアップが少し簡単ですが、ネイティブプラグインほどきれいではありません。
https://github.com/vishnubob/wait-for-it

また、次のような特定のプロセスを単純に待機することもできます。

# Wait until PHP FPM is up to start, since supervisord like to start everything at once...
# See
while [[ $(ps -aux | grep "[p]hp-fpm: master process") == "" ]];
do
    echo "Waiting for PHP FPM to come up..."
    sleep 2s
    if [[ $(ps -aux | grep "[p]hp-fpm: master process") != "" ]]; then
        echo "PHP FPM looks to be started, continuing with Icinga daemon initialization"
        ps -aux | grep "[p]hp-fpm: master process"
    fi
done

数が少ないので、この方法に落ち着きました

私が今気付いたのは、データベースとサーバーをホストするためにsupervisorを使用するとします。 サーバーサービスにはautorestart=trueがあり、データベースへの接続に失敗する限り、サーバーサービスは正しく再試行します。 だからそれはうまくいく。

+1

+1

+1

「+1」とコメントするだけでなく、元の投稿の親指をクリックしてください。 通知を見ると希望が浮かびます：D

この問題を解決するためのオプションとして、supervisor.confで、プログラムが自動開始値falseを取得することを定義します。例：

[プログラム：テスト]
自動開始：「false」
Command =“ / home / user / test”

2番目のステップは、bashスクリプトを使用してsupervisorctlの例を開始することです。

Gnome-terminal-e「監視対象」
Gnome-terminal -e“ supervisorctl”
睡眠10
Gnome-terminal-e「supervisorctlstarttest」

*アイデアをくれたAvnergidronに感謝します

こんにちは、
私はsupervisor.cnfファイルに以下のスクリプトがあります：

[プログラム：動物園の飼育係]
startsecs = 60
ディレクトリ= / app
command = / bin / bash -c "java -jar zoo.jar"
優先度= 1
autostart = true
自動再起動= true

[プログラム：kafka]
startsecs = 60
ディレクトリ= / app
command = / bin / bash -c "java -jar kaf.jar"
stdout_logfile = / var / log / Supervisor /％（program_name）s.log
stderr_logfile = / var / log / Supervisor /％（program_name）s.log
優先度= 999
autostart = true
自動再起動= true

最初にZookeeperを起動し、次にZookeeperが起動したときにKafkaを起動したいと思います。 このスクリプトは、期待どおりに機能しない場合があります。
スーパーバイザーを介してこれを処理する方法は何でしょうか。
提案してください。

@ kumarshorav11きれいではありませんが、私がしているのは、プロセスが最初に表示されるのを監視することです（待機する必要があるものは何でも）/。 これは単なる例です。

httpd.conf

[program:httpd]
command=/opt/supervisor/httpd_supervisor
autorestart=true
startretries=3
# Start only after PHP FPM
priority=2
# redirect output to stdout/stderr and do not use a regular logfile
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

/ opt / supervisor / httpd_supervisor：

#!/bin/bash

# Wait until PHP FPM is up to start, since supervisord likes to start everything at once...
# See https://github.com/Supervisor/supervisor/issues/122

echo -e "\n==> Starting httpd"
# PHP FPM
while [[ $(ps -aux | grep "[p]hp-fpm: master process") == "" ]];
do
    echo "Waiting for PHP FPM to come up to start httpd..."
    sleep 2s
    if [[ $(ps -aux | grep "[p]hp-fpm: master process") != "" ]]; then
        echo "PHP FPM looks to be started, continuing with Icinga daemon initialization"
        ps -aux | grep "[p]hp-fpm: master process"
    fi
done

# Another project had this, but we won't be using systemd
# service httpd start
/usr/sbin/httpd

# Allow any signal which would kill a process to stop server
trap "service httpd stop" HUP INT QUIT ABRT ALRM TERM TSTP

while pgrep -u apache httpd > /dev/null; do sleep 5; done

この問題を抱えている別のチームは、dnsmasqが正しく起動した後にのみアプリを起動する必要があります。そうでない場合、アプリは間違ったDNSを解決してキャッシュします。

それで、すでにhttps://github.com/jasoncorbett/ordered-startup-supervisordがあります、なぜこれがメインスーパーバイザーにマージされないのですか、これが修正されない理由はありますか？

編集：別の同様のフォークhttps://github.com/bendikro/supervisord-dependent-startup

エレガントな解決策はありますか？

私はこの機能のためにすべてです

この問題を追跡するのはここ数年楽しかったですが、私はついに購読を解除しました：joy：

私の場合は、手動で監視制御期間にないときに停止順序を制御したいだけですA > B 、 C 、
簡単な解決策：シェルスクリプトで、それらを1つずつ記述します。
supervisorctl stop A:*
supervisorctl stop B:* C:*
supervisorctl start A:* B:* C:*
または、 B 、 C以外の場合は、次のようにgrepを実行します
supervisorctl status | grep -v '^A:*' | grep -v '^B:*' | grep -v '^C:*' | awk -F':' '{print $1":*"}' | xargs | supervisorctl restart