Início / server / Perguntas / 211525
Accepted
grucha
Asked: 2010-12-12 00:48:55 +0800 CST

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

  • 772

Eu tenho um problema ao implantar o aplicativo Django usando Gunicorn e Supervisor. Embora eu possa fazer o Gunicorn servir meu aplicativo (definindo o PYTHONPATH adequado e executando o comando apropriado, o da configuração supervisord), não posso fazer o supervisor executá-lo. Ele simplesmente não verá meu aplicativo. Eu 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

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 continua dizendo myapp_live: ERROR (no such process). Alguma solução para isso?

deployment gunicorn supervisord

12 respostas

  1. 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. Tentar:

    supervisorctl reread
supervisorctl update
    • 264
  2. Best Answer

    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.

    • 44

  3. Certifique-se de que seus arquivos conf do supervisor terminem em .conf

    Demorei um pouco para descobrir isso. Espero que ajude a próxima pessoa.

    • 22

  4. 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 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
    • 15

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

    [program: myapp_live]

    quando deveria ter sido

    [program:myapp_live]

    Embora isso não aborde a pergunta que foi feita, fui conduzido aqui pela Pesquisa que procura uma solução para o meu problema, portanto, espero que outras pessoas também a encontrem aqui.

    • 7

  6. 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 afirma 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 de 3.0)." Então, talvez o problema tenha surgido pela primeira vez na versão 3.0.

    PS: Sou novo como 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.

    • 5

  7. 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, spam.ini seria incluído, mas spam.conf não.

    2. Se você criou o novo arquivo copiando um antigo, certifique-se de realmente alterar a [program:]linha. Porque se você for tão estúpido quanto ter dois arquivos para o mesmo programa, supervisorctl rereadvai te deixar com essa mensagem de erro sem esperança como punição:

      No config updates to processes

    3. Se seu arquivo for detectado, supervisorctl rereaddeve dizer algo como:

      spam: available

    4. Em seguida, supervisorctl update spamdeve iniciá-lo e fazê-lo aparecer em supervisorctl status.

    • 3

  8. Descobri que os scripts init.d não são confiáveis ​​em várias versões diferentes do Ubuntu/Debian. A maneira de fazer é esta:

    sudo supervisorctl reload
    • 2

  9. Achei esta solução mais conveniente:

    EDIT: antes de fazer isso, verifique o caminho do supervisorctl usando which supervisorctlpara garantir que você esteja adicionando o caminho certo 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 bastante restritos ao usuário que reinicia seu aplicativo gunicorn. Além disso, você não precisa se preocupar com pid. O comando não solicitará senha, portanto, é adequado para scripts bash/fabric de implantação automática. Por outro lado - você deve estar ciente de que, se supervisorctl estiver vulnerável a algum bug causando execução de código, um usuário mal-intencionado pode 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 tal vulnerabilidade).

    • 2

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

    Você pode ver que supervisorctl update (função do_update) está chamando reloadConfig() exatamente como supervisorctl reread (função do_reread) faz.

    Então eu acho que chamar reread não é necessário se você chamar update depois dele.

    A partir da saída do git culpado, tem sido assim desde pelo menos julho de 2009.

    • 2

relate perguntas