Como posso rastrear a causa da terminação do php-fpm?

Question

Tenho VPS (4 core, 6GB) rodando centos, nginx e php-fpm, com muito pouco tráfego (nunca publiquei o URL).

A cada poucas semanas (em momentos diferentes), o php-fpm termina com apenas o seguinte em php-fpm.log:

[10-Nov-2015 04:14:48] NOTICE: Terminating ...
[10-Nov-2015 04:14:48] NOTICE: exiting, bye-bye!

Não há outros eventos neste momento no nginx error.log ou no php-fpm-error.log.

• Onde mais posso procurar a causa dessa rescisão?

• Existe alguma coisa que eu possa configurar que me dê mais informações da próxima vez que isso acontecer?

• Posso configurar o php-fpm para reiniciar automaticamente?

Answer 1

Você pode usar o monit e seu teste de pid para que o php-fpm seja reiniciado quando ele falha e, opcionalmente, recebe um email quando isso acontece. Algo como

set mail-format {
From: [email protected]
Subject: $HOST $SERVICE $EVENT | $DATE
}

set alert [email protected]
check process php_fpm pidfile /var/run/php5-fpm.pid
 start program = "/etc/init.d/php5-fpm start"
 stop program = "/etc/init.d/php5-fpm stop"

O acima foi escrito com o Debian7 em mente, mas você também pode ajustá-lo ao CentOS.

    

Answer 2

Qual versão do PHP você usa? Você já tentou atualizar para o mais recente? Você instalou do rpm / deb ou compilou?

Você pode verificar se existe algum cron funcionando nesse momento?

Isso é freqüentemente causado por logrotate, tentando reiniciar o serviço.

De qualquer forma, a fim de evitar uma interrupção do serviço, você pode configurar o monit para verificar se o serviço está sendo executado e reiniciá-lo se não estiver. Ele também suporta notificações por email, assim você saberá sobre isso.

    

Answer 3

Os processos PHP não são particularmente confiáveis quando deixados em execução indefinidamente. Você deve configurar o php-fpm para reiniciar os processos de trabalho de vez em quando. Tente mudar

;pm.max_requests = 500

em

pm.max_requests = 500

para começar. Isso pode não corrigir tudo, pois você pode ter outros problemas de configuração, mas a alteração de max_requests é um bom começo. Meu servidor está em execução há meses sem qualquer tempo de inatividade.

A partir daqui