Processos apache2 não comutáveis

Question

Após a atualização do debian lenny para o squeeze (apache2 2.2.16-6 + squeeze4 e php 5.3.10-1 ~ dotdeb.1), meus processos apache começaram a sair com falha de segmentação. Isso acontece a cada 5 a 30 minutos (para 1 processo), por isso não causa nenhum impacto no momento. O problema é que, às vezes, em vez de sair com SIGSEGV , eles ficam loucos e fazem um loop com 100% de uso da CPU do sistema em SIGBUS error:

# strace -p27635
Process 27635 attached - interrupt to quit
--- SIGBUS (Bus error) @ 0 (0) ---
--- SIGBUS (Bus error) @ 0 (0) ---
--- SIGBUS (Bus error) @ 0 (0) ---
--- SIGBUS (Bus error) @ 0 (0) ---
--- SIGBUS (Bus error) @ 0 (0) ---
--- SIGBUS (Bus error) @ 0 (0) ---

Eles não respondem a kill -9 . Mas quando eu corro strace no processo depois de matá-lo, ele apenas repete o SIGBUS duas vezes e depois sai.

# strace -p27635
Process 27635 attached - interrupt to quit
--- SIGBUS (Bus error) @ 0 (0) ---
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGKILL +++

Por que o processo é inutilizável sem strace? Como o strace de execução influencia o processo que pode sair?

(Eu sei que provavelmente há algo errado com minha configuração de módulos apache / php, mas nesta questão eu estou interessado no comportamento estranho dos processos inutilizáveis. Vou fazer outra pergunta se eu não conseguir consertar o apache / php.)

    

Answer 1

Primeiro, verifique sua RAM.

Um processo que não responde ao SIGKILL é um sintoma de um bug do kernel ou de um bug de hardware. Quando você não mudou o seu kernel, a razão mais provável é que sua RAM está falhando, então verifique. Os bugs do kernel podem ter causas sutis (como usar a versão incorreta do gcc) e se manifestar de maneira sutil (como funcionar perfeitamente, exceto que o servidor X não iniciaria - a mesma história verdadeira). Não é muito provável que o seu novo kernel seja defeituoso, se você estiver usando o kernel fornecido pela distribuição que muitos outros usuários estão usando, mas isso pode acontecer - possivelmente um bug raro desencadeado por uma combinação de drivers e padrões de atividade. Tente outro kernel.

Também pode haver um bug no Apache que causa uma falha, mas se o SIGKILL não funcionar, não é culpa do Apache.