web-dev-qa-db-ja.com

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

DjangoアプリをGunicornとSupervisorを使用してデプロイする際に問題が発生しました。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)と言い続けるだけです。これに対する解決策はありますか？

deploymentsupervisordgunicorn
75
grucha

私は同じ問題を抱えていました

Sudo service supervisord reload

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

35
Hixi

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

supervisorctl reread
supervisorctl update
209
Mark Theunissen

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

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

17
nym

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

これを行う正しい方法は、supervisorctl rereadを発行することです。これにより、変更がないか構成ファイルがスキャンされます。

root@debian:~# supervisorctl reread
gunicorn: changed

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

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started
14
Burhan Khalid

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

[program: myapp_live]

あるべき時

[program:myapp_live]

これは、尋ねられた質問には対応していませんが、問題の解決策を探しているということで、私はここでリードされていました。

5
Conrad.Dean

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 を使用しています。

5
picomancer

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

Supervisorctl update（関数do_update）がreloadConfig（）を呼び出しており、supervisorctl reread（関数do_reread）とまったく同じであることがわかります。

そのため、更新後にupdateを呼び出す場合、rereadを呼び出す必要はないと思います。

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

2
Sebastien Estienne

私はこの解決策が最も便利であることを発見しました：

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

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

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

そして単に：

Sudo supervisorctl restart myapp

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

2
pielgrzym

ここにチェックリストがあります：

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

    [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に表示する必要があります。

2
user2394284

Init.dスクリプトは、さまざまなUbuntu/Debianバージョンで信頼できないことがわかりました。それを行う方法はこれです：

Sudo supervisorctl reload
1
mafrosis

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

1
Leo Pepe

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

0
Aidas