Capistrano não reiniciando os aglomerados de mestrado adequadamente

Question

Eu tenho um cluster de três mexéis em execução no NGINX e implantei o aplicativo usando o Capistrano 2.4.3. Quando eu "implantar" quando existe um sistema em execução, o comportamento é:

1. O aplicativo é implantado. O código é atualizado com sucesso.

2. Na saída da implantação do CAP, existe o seguinte:

   • Execução da senha "sudo -p 'sudo:' Mongrel_rails cluster :: rewert -c /var/www/rails/myapp/current/config/mongrel_cluster.yml"
   • Servidores: ["myip"
   • myip] Execução do comando
   • ** [Out :: Myip] Parando a porta 9096
   • ** [Out :: Myip] Parando a porta 9097
   • ** [Out :: Myip] Parando a porta 9098
   • ** [Out :: Myip] já iniciou a porta 9096
   • ** [Out :: Myip] já iniciou a porta 9097
   • ** [Out :: Myip] já iniciou a porta 9098
3. Verifico imediatamente no servidor e acho que o MonGrel ainda está em execução, e os arquivos PID ainda estão presentes nas três instâncias anteriores.
4. Pouco tempo depois (menos de um minuto), acho que o Mongrel não está mais em execução, os arquivos PID desapareceram e não conseguiu reiniciar.
5. Se eu iniciar o MonGrel no servidor manualmente, o aplicativo será iniciado muito bem.

Parece que 'Mongrel_Rails Cluster :: Reiniciar' não está esperando corretamente por um ponto final antes de tentar um reinício do cluster. Como faço para diagnosticar e corrigir esse problema?

EDIT: Aqui está a resposta:

Mongrel_cluster, na tarefa "reiniciar", simplesmente faz isso:

 def run
   stop
   start
 end

Não faz nenhuma espera ou verificação para ver se o processo saiu antes de invocar "Start". Isto é um bug conhecido com um excelente patch enviado. Apliquei o patch no cluster de mestrado e o problema desapareceu.

Answer 1

Você pode dizer explicitamente às receitas de MonGrel_cluster para remover os arquivos PID antes de começar, adicionando o seguinte em suas receitas Capistrano:

# helps keep mongrel pid files clean
set :mongrel_clean, true

Isso faz com que ele passe a opção -limpe para MONGREL_CLUSTER_CTL.

Voltei e olhei para uma das minhas receitas de implantação e notei que também havia mudado a maneira como minha tarefa de reinicialização funcionava. Dê uma olhada na seguinte mensagem no grupo de usuários do MonGrel:

Discussão dos usuários do MonGrel sobre reinicialização

A seguir, é apresentada a minha tarefa de implantação: reiniciar. Eu admito que é um pouco um hack.

namespace :deploy do
  desc "Restart the Mongrel processes on the app server."
  task :restart, :roles => :app do
    mongrel.cluster.stop
    sleep 2.5
    mongrel.cluster.start
  end
end

Answer 2

Primeiro, restrinja o escopo do que seus testes chamam apenas cap deploy:restart. Você pode querer passar pelo --debug opção para solicitar antes da execução remota ou da --dry-run opção apenas para ver o que está acontecendo ao ajustar suas configurações.

À primeira vista, isso soa como uma questão de permissões nos arquivos PID ou nos processos de MonGrel, mas é difícil saber com certeza. Algumas coisas que chamam minha atenção são:

• a :runner A variável é explícita definida como nil - Houve uma razão específica para isso?
• Capistrano 2.4 introduziu um novo comportamento para o :admin_runner variável. Sem ver a receita inteira, isso está possivelmente relacionado ao seu problema?

  : corredor vs.: admin_runner (a partir de Capistrano 2.4 Release) Alguns capitpers observaram que, tendo implantado: configurar e implantar: a limpeza executada como: o usuário do corredor interrompeu suas permissões cuidadosamente criadas. Eu concordei que isso era um problema. Com esta versão, Implante: Iniciar, Implantar: Pare e Implante: reinicie tudo continue usando o: Usuário do corredor ao sudoing, mas implante: Configurar e implantar: a limpeza usará o: admin_runner User. A variável: admin_runner não é definida, por padrão, o que significa que essas tarefas vão sudo como root, mas se você quiser que elas sejam executadas como: corredor, basta fazer "set: admin_runner, corredor".

Minha recomendação para o que fazer a seguir. Pare manualmente os mexéis e limpe os PIDs. Comece os mexéis manualmente. Em seguida, continue a correr cap deploy:restart enquanto depura o problema. Repita conforme necessário.

Answer 3

De qualquer forma, meus mexéis estão começando antes do comando de parada anterior terminar de desligá -los.

O sono 2.5 não é uma boa solução, se levar mais de 2,5 segundos para interromper todos os mexéis em execução.

Parece haver uma necessidade de:

stop && start

vs.

stop; start

(É assim que o Bash funciona, && aguarda o primeiro comando terminar sem erro, enquanto ";" simplesmente executa o próximo comando).

Gostaria de saber se existe um:

wait cluster_stop
then cluster_start

Answer 4

Eu odeio ser tão básico, mas parece que os arquivos PID ainda estão por aí quando estão tentando começar. Certifique -se de que o Mongrel esteja parado à mão. Limpe os arquivos PID manualmente. Em seguida, faça uma captura de capital.

Answer 5

Boa discussão: http://www.ruby-forum.com/topic/139734#745030