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


68

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). 이것에 대한 해결책?


나는 같은 문제로 머리를 긁었다. reread또는을 실행할 때 구성 파일이로드되지 않았습니다 update. 구성 파일을 저장 foo.conf.py하지 않고 대신 저장 foo.conf하지 않은 것으로 나타났습니다.
Timmy O'Mahony

답변:


31

나는 같은 문제가 있었다.

sudo service supervisord reload

그것이 당신의 질문에 대한 대답인지는 모르겠지만 트릭을했습니다.


2
나는 얼마 전에 감독자를 멈췄다가 시작했다.
새로

나도 그 일을했다. /etc/init.d/supervisor restart수동 중지 및 시작시 왜 작동하지 않는지 궁금 합니다.
키릴

1
서비스가 작동하지 않았지만 방금 실행 ps aux | grep supervisor한 다음sudo kill -HUP pid
Wayne Werner

2
전체 수퍼바이저 데몬을 다시 시작하므로 위험합니다.
Mark Theunissen

7
supervisorctl reread는 서비스를 다시 시작하지 않고도이 문제를 해결할 수 있습니다.
Jonathan Liuti

199

정답은 상사가 당신이 다시 읽어 필요로한다는 것이다 새 구성 파일을 배치 할 때 갱신. 다른 서비스에 영향을 미치므로 다시 시작하는 것이 답이 아닙니다. 시험:

supervisorctl reread
supervisorctl update

13
이것이 정답이어야합니다. "감독자 재 읽기"만으로는 충분하지 않습니다.
Miebster

3
+1 이것은 프로세스 관리자에 의존하지 않기 때문에 더 나은 대답입니다.
tidwall

8
"supervisorctl reread"만으로는 충분하지 않지만 "supervisorctl update"로는 충분하지 않습니까? 문서 "업데이트"에 따르면, 다시 읽은 후에 구성을 다시 읽은 모든 프로그램을 다시 시작합니다.
BlueBomber

그것은 나를 위해 작동합니다. 나중에 다시 시작했습니다.
user1012513

15

관리자 conf 파일이 .conf로 끝나는 지 확인하십시오.

저것을 알아내는 데 시간이 걸렸습니다. 잘하면 그것은 다음 사람에게 도움이됩니다.


1
같은 문제로 한 시간을 낭비했습니다. 이것이 단순하다는 것을 믿을 수 없습니다.
Zane Hooper

1
이 답변을 나열 해 주셔서 감사합니다. 내 인생에서 나는 이것을 알아낼 수 없었다.
Phillip Martin

14

마스터 수퍼바이저 프로세스를 다시로드해도 작동 할 수 있지만 수퍼바이저가 둘 이상의 프로세스를 모니터링하는 경우 의도하지 않은 부작용이 있습니다.

올바른 방법은 supervisorctl reread구성 파일에서 변경 사항을 스캔하도록하는 것입니다.

root@debian:~# supervisorctl reread
gunicorn: changed

그런 다음 해당 앱을 다시로드하십시오.

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

변경된 / 새 구성 파일 만 읽고 나머지 실행중인 프로세스는 그대로 유지하려는 경우이 방법이 가장 좋습니다. Supervisorctl은 새로운 앱이 표시됩니다 avail. 발행하여 (재) 시작 가능한 프로세스에 추가하십시오 supervisorctl update. 또한 마크의 답변을 참조하십시오 serverfault.com/a/479754/125887
Sjaak Trekhaak

4
이것은 충분하지 않았습니다. supervisorctl update필요했다.
Yaroslav Nikitenko

5

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 를 사용하고 있습니다 .


4

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

[program: myapp_live]

그것이 있어야 할 때

[program:myapp_live]

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


여기 동일합니다! 나는 [program]문서에 따라 그것을 그대로 두었지만 그것이 [program:redis]나를 위해 일 하게 만들었습니다. 상황이 때때로 이상해집니다!
ankush981

2

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

편집 :이 작업을 수행하기 전에 수퍼바이저 경로를 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 권한을 사용하여 코드를 루트로 실행할 수 있습니다 (그러나 그러한 버그가 감독자에게 발견되지 않은 한 그러한 취약점을 찾는 것은 큰 일입니다).


2

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

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

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

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


2

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

  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합니다.


1

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

sudo supervisorctl reload

많은 상황에서 작동하지만 올바른 방법은 아닙니다. @ burhan-khalid 답변이 올바른 답변이며 이에 대한 설명을 제공합니다.
glarrain

1

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


0

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


이것은 또한 내 문제였으며 모든 Centos 6.5 이하 설치에서 발생할 수 있습니다.
bearrito
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.