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.
Eu tenho um problema ao implantar o aplicativo Django usando Gunicorn e Supervisor. Enquanto eu posso fazer o Gunicorn servindo meu aplicativo (definindo o PYTHONPATH correto e executando o comando apropriado, aquele da configuração do supervisord) eu não posso fazer o supervisor rodá-lo. Apenas não verá meu aplicativo. Eu não sei como ter certeza se o arquivo de configuração está ok.
Veja o que o supervisorctl diz:
# supervisorctl start myapp_live
myapp_live: ERROR (no such process)
Eu estou rodando 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
Em /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 supervisorctl apenas continue dizendo myapp_live: ERROR (no such process) . Alguma solução para isso?
A resposta correta é que o supervisor exige que você leia e novamente quando você colocar um novo arquivo de configuração. Reiniciar não é a resposta, pois isso afetará outros serviços. Experimente:
supervisorctl reread
supervisorctl update
Verifique se os arquivos conf do supervisor terminam em .conf
Demorei um tempo para descobrir isso. Espero que ajude a próxima pessoa.
Recarregar o processo do supervisor mestre pode funcionar, mas ele terá efeitos colaterais indesejados se você tiver mais de um processo sendo monitorado pelo supervisor.
A maneira correta de fazer isso é emitir supervisorctl reread , o que faz com que ele verifique os arquivos de configuração em busca de alterações:
root@debian:~# supervisorctl reread
gunicorn: changed
Em seguida, basta recarregar esse aplicativo:
root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started
Eu encontrei este problema usando o pacote de supervisor, versão 3.0a8-1.1 do Ubuntu Server 12.10. Acabei resolvendo o problema lendo a ajuda integrada:
$ 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ê quer usar a sintaxe:
sudo supervisorctl restart myapp_live:*
Como a documentação declara em link - "A seção [program: x] na verdade representa um" homogêneo grupo de processo ”para o supervisor (a partir de 3.0)." Então, talvez o problema tenha surgido pela primeira vez na versão 3.0.
PS: sou novo no supervisor; Estou usando o link como um exemplo do que uma configuração mínima deve parece.
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 resolva a pergunta que foi feita, eu fui liderado aqui pela Pesquisa que está procurando uma solução para o meu problema, então espero que outras pessoas também o encontrem aqui.
Eu achei esta solução mais conveniente:
EDIT: antes de fazer isso, verifique seu caminho de supervisorctl usando which supervisorctl para ter certeza de que você está adicionando o caminho certo para os 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á preso aos scripts de inicialização da distribuição e concede privilégios bastante restritos ao usuário que está reiniciando seu aplicativo gunicorn. Além disso, você não precisa se preocupar com pid. O comando não pedirá senha, por isso é adequado para scripts bash / fabric de auto-implantação. Por outro lado - você deve estar ciente de que, se supervisorctl estiver vulnerável a algum bug que causa execução de código, um usuário mal-intencionado poderia usar esse privilégio sudo para executar código como root (mas, até onde eu sei, nenhum bug foi descoberto para supervisord e é uma grande coisa encontrar essa vulnerabilidade).
Lendo o código do supervisorctl.py aqui: link
Você pode ver que supervisorctl update (função do_update) está chamando reloadConfig () exatamente como supervisorctl reler (função do_reread).
Então, eu acho que chamar a releitura não é necessário se você chamar a atualização depois dela.
A saída do git blame tem sido assim desde pelo menos desde julho de 2009.
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 é isso:
sudo supervisorctl reload
Tenha cuidado com links simbólicos e inclua arquivos no Supervisor. Ele permitiria que qualquer pessoa com privilégio em /home/myapp/live/deploy/supervisord_live.ini altere o arquivo ini e inicie qualquer código malicioso. Esses arquivos ini devem estar dentro do diretório conf do supervisor ou em qualquer subdiretório abaixo dele.
Aqui está uma lista de verificação:
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, spam.ini seria incluído, mas o spam.conf não.
Se você criou o novo arquivo copiando um antigo, certifique-se de alterar realmente a linha [program:] . Porque se você for tão estúpido quanto ter dois arquivos para o mesmo programa, supervisorctl reread deixará você com essa mensagem de erro sem esperança como punição:
No config updates to processes
Se o seu arquivo for detectado, supervisorctl reread deve dizer algo como:
spam: available
Em seguida, supervisorctl update spam deve iniciá-lo e torná-lo exibido em supervisorctl status .
Eu tinha instalado o supervisrod com o yum install, que instalava o supervisor da versão v2. *. Supervisor suporta external includes apenas da versão 3. Teve que usar o easy_install em vez disso, para instalar o supervisor v3.