スーパーバイザーが新しい構成ファイルをロードしない

GunicornとSupervisorを使用してDjangoアプリを展開する際に問題があります。Gunicornにアプリを提供させることはできますが（適切なPYTHONPATHを設定し、supervisord configからの適切なコマンドを実行することにより）、スーパーバイザーに実行させることはできません。アプリが表示されません。構成ファイルに問題がないかどうかを確認する方法がわかりません。

Supervisorctlの説明は次のとおりです。

# supervisorctl start myapp_live
myapp_live: ERROR (no such process)

私はUbuntu 10.04で次の設定で実行しています：

ファイル/home/myapp/live/deploy/supervisord_live.ini：

[program:myapp_live]
command=/usr/local/bin/gunicorn_django --log-file /home/myapp/logs/gunicorn_live.log --log-level info --workers 2 -t 120 -b 127.0.0.1:10000 -p deploy/gunicorn_live.pid webapp/settings_live.py
directory=/home/myapp/live
environment=PYTHONPATH='/home/myapp/live/eco/lib'
user=myapp
autostart=true
autorestart=true

/etc/supervisor/supervisord.confのファイルの最後には、次のものがあります。

[include]
files = /etc/supervisor/conf.d/*.conf

ここに私の設定ファイルへのシンボリックリンクがあります：

# ls -la /etc/supervisor/conf.d
lrwxrwxrwx 1 root root   48 Dec  4 18:02 myapp-live.conf -> /home/myapp/live/deploy/supervisord_live.ini

私にはすべてがうまく見えますが、supervisorctlは言い続けますmyapp_live: ERROR (no such process)。これに対する解決策はありますか？

同じ問題がありました

sudo service supervisord reload

トリックをしましたが、それがあなたの質問に対する答えかどうかはわかりませんが。

正しい答えは、新しい構成ファイルを配置する場合、スーパーバイザーは再読み取りと更新を要求するということです。他のサービスに影響を与えるため、再起動は答えではありません。試してください：

supervisorctl reread
supervisorctl update

スーパーバイザーのconfファイルが.confで終わることを確認してください

それを理解するのにしばらくかかった。うまくいけば、それは次の人を助ける。

マスタースーパーバイザプロセスのリロードは機能する場合がありますが、スーパーバイザによって監視されているプロセスが複数ある場合、意図しない副作用が発生します。

それを行う正しい方法は、supervisorctl reread設定ファイルをスキャンして変更がないかを発行することです。

root@debian:~# supervisorctl reread
gunicorn: changed

次に、そのアプリをリロードします。

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started

Ubuntu Server 12.10のスーパーバイザーパッケージバージョン3.0a8-1.1を使用してこの問題が発生しました。私は組み込みのヘルプを読んで問題を解決することになりました：

$ sudo supervisorctl help restart
restart <name>          Restart a process
restart <gname>:*       Restart all processes in a group
restart <name> <name>   Restart multiple processes or groups
restart all             Restart all processes

特に、次の構文を使用します。

sudo supervisorctl restart myapp_live:*

ドキュメントがhttp://supervisord.org/configuration.html#programx-sectionで述べているように、「[program：x]セクションは実際にはスーパーバイザーに対する「均質なプロセスグループ」を表します（3.0以降）。」そのため、バージョン3.0で最初に問題が表面化したのかもしれません。

PS：私はスーパーバイザーが初めてです。最小構成がどのように見えるかの例として、https：//github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisorを使用しています。

同様の問題（myapp_live: ERROR (no such process)）がありましたが、それはプロセス定義が

[program: myapp_live]

あるべき時

[program:myapp_live]

これは尋ねられた質問に対処するものではありませんが、私はここで私の問題の解決策を探しているSearchに率いられました。

私はこの解決策が最も便利だと感じました：

編集：これを行う前にwhich supervisorctl、sudoersに正しいパスを追加していることを確認するためにsupervisorctlパスを確認してください。

次を使用して、この行をsudoersファイルに追加しますvisudo（場所：myappuser-アプリを再起動する必要があるユーザー、myapp-アプリ名）：

myappuser  ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp

そして単純に：

sudo supervisorctl restart myapp

ディストリビューションの起動スクリプトに縛られず、gunicornアプリを再起動するユーザーに非常に狭い権限を与えます。また、pidを気にする必要はありません。このコマンドはパスワードを要求しないため、自動展開のbash / fabricスクリプトに適しています。一方、supervisorctlがコード実行の原因となるバグに対して脆弱な場合、悪意のあるユーザーがこのsudo特権を使用してコードをrootとして実行できることに注意する必要があります（ただし、supervisordおよびそのような脆弱性を見つけることは大きなことです）。

ここでsupervisorctl.pyのコードを読む：https : //github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Supervisorctlの更新（関数do_update）が、supervisorctlの再読み込み（関数do_reread）とまったく同じようにreloadConfig（）を呼び出していることがわかります。

したがって、更新後に呼び出した場合、再読み取りを呼び出す必要はないと思います。

git blameの出力から、少なくとも2009年7月以降、このようになっています。

チェックリストは次のとおりです。

1. 新しい設定ファイルには、/ etc / supervisord.confで設定されたincludeパターンに従って名前を付ける必要があります。

   [include]
   files=supervisord.d/*.ini
   

   私の場合、spam.iniは含まれていますが、spam.confは含まれていません。

2. 古いファイルをコピーして新しいファイルを作成した場合は、実際に[program:]行を変更してください。同じプログラムに対して2つのファイルを持っているのと同じくらい愚かなsupervisorctl reread場合、この絶望的なエラーメッセージが罰として残されるためです。

   No config updates to processes
   

3. ファイルが検出されたら、supervisorctl reread次のように言う必要があります。

   spam: available
   

4. 次に、supervisorctl update spam両方を起動し、に表示する必要がありsupervisorctl statusます。

init.dスクリプトは、Ubuntu / Debianのさまざまなバージョンで信頼できないことがわかりました。その方法は次のとおりです。

sudo supervisorctl reload

シンボリックリンクに注意し、Supervisorのファイルを含めます。/home/myapp/live/deploy/supervisord_live.iniでw権限を持つすべてのユーザーがiniファイルを変更し、悪意のあるコードを開始できるようになります。このiniファイルは、スーパーバイザーのconfディレクトリまたはその下のサブディレクトリにある必要があります。

バージョンv2。*のスーパーバイザーをインストールするyum installでsupervisrodをインストールしました。スーパーバイザーは、バージョン3からのみ外部インクルードをサポートしています。代わりに、easy_installを使用してスーパーバイザーv3をインストールする必要がありました。