감독자가 새 구성 파일을로드하지 않음

Gunicorn과 Supervisor를 사용하여 Django 앱을 배포하는 데 문제가 있습니다. 적절한 PYTHONPATH를 설정하고 적절한 명령 (supervisord config의 명령)을 실행하여 Gunicorn이 내 앱을 제공하도록 할 수는 있지만 관리자가 실행하도록 관리자를 만들 수는 없습니다. 내 앱이 표시되지 않습니다. 구성 파일이 올바른지 확인하는 방법을 모르겠습니다.

supervisorctl이 말한 내용은 다음과 같습니다.

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

우분투 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에 나와있는 것처럼 "[프로그램 : x] 섹션은 실제로 관리자에게"균일 한 프로세스 그룹 "을 나타냅니다 (3.0 기준)." 따라서 문제는 3.0 버전에서 처음 나타났습니다.

추신 : 저는 감독자를 처음 접했습니다. 최소 구성이 어떻게 보이는지에 대한 예로 https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor 를 사용하고 있습니다 .

비슷한 문제 ( myapp_live: ERROR (no such process))가 있었고 프로세스 정의가

[program: myapp_live]

그것이 있어야 할 때

[program:myapp_live]

이것은 묻는 질문을 다루지 않지만, 나는 내 문제에 대한 해결책을 찾고있는 검색에 의해 여기에서 인도되었으므로 다른 사람들도 여기에서 찾을 수 있기를 바랍니다.

이 솔루션이 가장 편리하다는 것을 알았습니다.

편집 :이 작업을 수행하기 전에 수퍼바이저 경로를 which supervisorctl확인하여 sudoers에 올바른 경로를 추가하고 있는지 확인하십시오.

다음을 사용하여 sudoers 파일에이 행을 추가하십시오 visudo(여기서 -앱 myappuser을 다시 시작해야하는 사용자 myapp-앱 이름).

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

그리고 간단히 :

sudo supervisorctl restart myapp

배포판 시작 스크립트에 묶여 있지 않으며 gunicorn 앱을 다시 시작하는 사용자에게 매우 좁은 권한을 부여합니다. 또한 pid를 신경 쓸 필요가 없습니다. 이 명령은 암호를 요구하지 않으므로 자동 배포 bash / fabric 스크립트에 적합합니다. 반면에-supervisorctl이 코드 실행을 일으키는 일부 버그에 취약한 경우 악의적 인 사용자 가이 sudo 권한을 사용하여 코드를 루트로 실행할 수 있습니다 (그러나 그러한 버그가 감독자에게 발견되지 않은 한 그러한 취약점을 찾는 것은 큰 일입니다).

https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py 에서 supervisorctl.py의 코드를 읽으십시오.

supervisorctl 업데이트 (기능 do_update)가 supervisorctl reread (기능 do_reread)와 정확히 동일하게 reloadConfig ()를 호출하고 있음을 알 수 있습니다.

따라서 업데이트 후 호출하면 다시 읽기 호출이 필요하지 않다고 생각합니다.

git blame의 출력에서 ​​적어도 2009 년 7 월 이후로 이와 같았습니다.

점검 목록은 다음과 같습니다.

1. 새 설정 파일은 /etc/supervisord.conf에 구성된 포함 패턴에 따라 이름이 지정되어야합니다.

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

   필자의 경우 spam.ini는 포함되지만 spam.conf는 포함되지 않습니다.

2. 이전 파일을 복사하여 새 파일을 만든 경우 실제로 [program:]줄을 변경해야 합니다. 동일한 프로그램에 대해 두 개의 파일을 갖는 것만 큼 어리석은 supervisorctl reread경우이 절망적 인 오류 메시지가 처벌로 남습니다.

   No config updates to processes
   

3. 파일이 감지되면 supervisorctl reread다음과 같이 말해야합니다.

   spam: available
   

4. 그런 다음 supervisorctl update spam시작하여에 나타나야 supervisorctl status합니다.

다양한 우분투 / 데비안 버전에서 init.d 스크립트를 신뢰할 수 없다는 것을 알았습니다. 이를 수행하는 방법은 다음과 같습니다.

sudo supervisorctl reload

심볼릭 링크에주의하고 Supervisor에 파일을 포함 시키십시오. /home/myapp/live/deploy/supervisord_live.ini에 대한 권한이있는 사람은 ini 파일을 변경하고 악성 코드를 시작할 수 있습니다. 이 ini 파일은 감독자의 conf 디렉토리 또는 그 아래의 하위 디렉토리에 있어야합니다.

버전 v2. *의 관리자를 설치 한 yum install로 supervisrod를 설치했습니다. Supervisor는 버전 3의 외부 포함 만 지원합니다. 대신 supervisor v3을 설치하기 위해 easy_install을 사용해야했습니다.