Supervisor não carregando novos arquivos de configuração

Estou com um problema ao implantar o aplicativo Django usando o Gunicorn e o Supervisor. Embora eu possa fazer o Gunicorn servir meu aplicativo (definindo PYTHONPATH adequado e executando um comando apropriado, o da supervisord config), não posso fazer o supervisor executá-lo. Simplesmente não verá meu aplicativo. Não sei como ter certeza se o arquivo de configuração está ok.

Aqui está o que supervisorctl diz:

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

Estou executando-o no Ubuntu 10.04 com a seguinte configuração:

Arquivo /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

No arquivo /etc/supervisor/supervisord.conf, no final do arquivo, há:

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

e aqui está um link simbólico para o meu arquivo de configuração:

# 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

tudo parece bem para mim, mas o supervisorctl continua dizendo myapp_live: ERROR (no such process). Alguma solução para isso?

Eu tive o mesmo problema, um

sudo service supervisord reload

fez o truque, embora eu não saiba se essa é a resposta para sua pergunta.

A resposta correta é que o supervisor exige que você releia e atualize quando colocar um novo arquivo de configuração. Reiniciar não é a resposta, pois isso afetará outros serviços. Experimentar:

supervisorctl reread
supervisorctl update

Verifique se os arquivos conf do supervisor terminam em .conf

Levei um tempo para descobrir isso. Espero que ajude a próxima pessoa.

Recarregar o processo do supervisor mestre pode funcionar, mas terá efeitos colaterais indesejados se você tiver mais de um processo sendo monitorado pelo supervisor.

A maneira correta de fazer isso é emitir o supervisorctl rereadque faz com que varra os arquivos de configuração em busca de quaisquer alterações:

root@debian:~# supervisorctl reread
gunicorn: changed

Em seguida, basta recarregar o aplicativo:

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

Encontrei esse problema usando o pacote supervisor, versão 3.0a8-1.1, do Ubuntu Server 12.10. Acabei resolvendo o problema lendo a ajuda interna:

$ 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

Em particular, você deseja usar a sintaxe:

sudo supervisorctl restart myapp_live:*

Como a documentação declara em http://supervisord.org/configuration.html#programx-section - "Uma seção [program: x] na verdade representa um" grupo de processos homogêneo "para o supervisor (a partir do 3.0)." Talvez o problema tenha surgido na versão 3.0.

PS: Sou novo no supervisor; Estou usando https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor como um exemplo de como deve ser uma configuração mínima.

Eu tive um problema semelhante ( myapp_live: ERROR (no such process)) e foi porque minha definição de processo era

[program: myapp_live]

quando deveria ter sido

[program:myapp_live]

Embora isso não atenda à pergunta que foi feita, fui liderado aqui pela pesquisa que procura uma solução para o meu problema, por isso espero que outras pessoas a encontrem aqui também.

Eu achei esta solução a mais conveniente:

EDIT: antes de fazer isso, verifique o caminho do supervisorctl usando which supervisorctlpara garantir que você está adicionando o caminho correto aos sudoers.

Adicione esta linha ao arquivo sudoers usando visudo(onde: myappuser- o usuário que precisa reiniciar seu aplicativo, myapp- nome do aplicativo):

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

E então simplesmente:

sudo supervisorctl restart myapp

Você não está vinculado aos scripts de inicialização da distribuição e concede privilégios limitados ao usuário que reinicia o aplicativo gunicorn. Além disso, você não precisa se preocupar com pid. O comando não solicitará a senha, portanto, é adequado para scripts bash / fabric de implantação automática. Por outro lado - você deve estar ciente de que, se o supervisorctl estiver vulnerável a algum bug que causa a execução do código, um usuário mal-intencionado pode usar esse privilégio sudo para executar o código como root (mas, tanto quanto eu sei, nenhum bug foi descoberto para supervisão e é importante encontrar essa vulnerabilidade).

Leia o código de supervisorctl.py aqui: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Você pode ver que a atualização do supervisorctl (função do_update) está chamando reloadConfig () exatamente como supervisorctl reler (função do_reread).

Então eu acho que não é necessário chamar a releitura se você chamar a atualização depois dela.

A partir da saída da culpa do git, é assim desde pelo menos desde julho de 2009.

Aqui está uma lista de verificação:

1. O novo arquivo de configuração deve ser nomeado de acordo com o padrão de inclusão configurado em /etc/supervisord.conf:

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

   Como vemos no meu caso, o spam.ini seria incluído, mas o spam.conf não.

2. Se você criou o novo arquivo copiando um antigo, altere a [program:]linha. Porque se você é tão estúpido quanto ter dois arquivos para o mesmo programa, supervisorctl rereaddeixará essa mensagem de erro sem esperança como punição:

   No config updates to processes
   

3. Se o seu arquivo for detectado, supervisorctl rereaddiga algo como:

   spam: available
   

4. Em seguida, supervisorctl update spaminicie e faça aparecer supervisorctl status.

Eu descobri que os scripts init.d não são confiáveis ​​em uma variedade de versões diferentes do Ubuntu / Debian. A maneira de fazer isso é esta:

sudo supervisorctl reload

Cuidado com links simbólicos e inclua arquivos no Supervisor. Isso permitiria a qualquer pessoa com privilégio w em /home/myapp/live/deploy/supervisord_live.ini alterar o arquivo ini e iniciar qualquer código malicioso. Esses arquivos ini devem estar dentro do diretório conf do seu supervisor ou em qualquer subdiretório abaixo dele.

Instalei o supervisrod com o yum install, que instalou o supervisor da versão v2. *. O Supervisor suporta inclusões externas apenas a partir da versão 3. Em vez disso, foi necessário usar o easy_install para instalar o supervisor v3.