Pouco de uma situação desconcertante com a qual tenho lidado por alguns dias. Eu tenho vários servidores headless CentOS (6.4) com as seguintes estatísticas:
Core
SE Status: desativado (eu sei, eu sei)
Pacotes
libpri-1.4.12-6_centos6.x86_64
libpridevel - 1.4.12-6_centos6.x86_64
dahdi-firmware-oct6114-128-1.05.01-119_centos5.noarch
dahdi-linux-2.7.0-18_centos6.x86_64
Quando esta configuração funciona, funciona muito bem. Dez servidores em locais diferentes executando este mesmo hardware e software de configuração. Três dos dez servidores, no entanto, continuam bloqueando. Ao bloquear, quero dizer completamente sem resposta na rede e nenhuma chamada telefônica pode ser enviada ou recebida. É necessário um desligamento / reinicialização do servidor para que ele se torne operacional novamente.
/ var / log / messages, dmesg e dmesg, old param de gravar quando o sistema trava, mas não há erros, erros de hardware, pânicos, etc nos logs. / var / log / boot mostra uma inicialização normal, apenas alguns avisos sobre o prodígio (que não é usado). / var / log / mcelog está sempre vazio, sem contagem de linhas ou texto. /var/log/freepbx.log mostra linhas INFO normais.
Não há padrão para o período de tempo ou a carga de trabalho dos servidores que se correlacionam ao bloqueio. Às vezes, será por três horas, às vezes por três dias. Sensores show temp está sempre dentro do intervalo e nenhum registro de limite da CPU é registrado. Eu instalei o kdump e configurei os parâmetros do kernel para entrar em pânico com softlockup e pendurar tarefas, bem como com os padrões. O kdump.conf foi alterado para a reinicialização padrão. Quando eu manualmente SYSRQ C (kernel panic), o kdump é acionado e despeja um arquivo de falha (embora por algum motivo ele não seja reinicializado automaticamente depois disso). O uso de SAR para cpu nunca é superior a 5% de utilização, a memória nunca ultrapassa 10% de utilização. O HDD rd_sec atinge o pico em 5.86, o wr_sec atinge o máximo em 120. O Max util tem uma média de 7%.
Eu corri memtester e estresse no sistema, tentando fazê-lo falhar, sem sucesso (o sistema precisa permanecer para cima, se possível). O Memtester rodando com 512M e 50 iterações, até 2048M e 100 iterações, todos testaram "ok" sem problemas.
Não vejo nenhum motivo para o travamento dessas caixas, ou porque o kdump não está sendo acionado (se é um kernel panic). Eu exaurei minhas habilidades de pesquisa de log em tentativas de encontrar uma razão para esse comportamento.
Alguém mais tem uma ideia de onde eu poderia procurar, ou o que eu poderia fazer para identificar o problema aqui, por favor?