Não atualize o Zend Optimizer para Versão 3.0 - Problemas com arquivos core
Nas últimas 24 horas, mais ou menos, tive que travar uma batalha com o servidor, em função da atualização do [tag]Zend[/tag] Optimazer 3.0.
Nesses últimos 2 dias, esse [tag]servidor[/tag], começou a apresentar um comportamento muito estranho, causando [tag]erros[/tag] de acesso ao [tag]MySql[/tag], ftp etc..., desempenho bem abaixo do normal e chegou a sair do ar.
Começou, então, minha via crucis.
Uma longa investigação e vários passos foram necessários para colocar o servidor de volta ao funcionamento normal, vou relatar o que eu fiz, para que, se alguém tiver o mesmo problema, não sofra o que eu sofri.
PS.: Sempre que eu colocar algum comando, será via ssh como root.
Ao acessar o
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
, existia uma mensagem de aviso de problemas de segurança com a combinação de versão do Apache,
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
, [tag]php[/tag] e SO do meu servidor, nÃvel de criticidade mediano, então nada para se preocupar, mas como estava tendo problemas com o MySql, resolvi atualizar logo.
Segui os procedimentos padrões de atualizações para colocar tudo nas versões que corrigiriam o problema, feliz da vida, achando que isso resolveria a situação.
Ledo engano, as coisas só pioraram, depois de muita pesquisa, descobri que a última versão do easyapache (script de atualização do Apache do [tag]WHM[/tag]) veio com problemas e que eu teria que derrubar o Apache antes de fazer a atualização para que essa fosse concluÃda.
Como o servidor tem proteção contra queda do Apache, tive que primeiro derrubar a proteção, para depois derrubar o Apache, com os seguintes comandos:
# service chkservd stop
# service httpd stop
Com o
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
fora de ação, consegui atualizar o mesmo, junto com o PHP.
Próximo passo foi atualizar o MySql para versão 4.1, o que me trouxe um sério inconveniente, pois alguns scripts para a versão 4.0 não conseguiam acessar as bases de dados, fiz nova atualização, marcando a opção de manter a compatibilidade de login com a versão 4.0.
Os scripts voltaram a acessar as bases de dados, mas o servidor continuava apresentando problemas.
Comecei, então, tentando identificar porque isso estava acontecendo, usei algumas ferramentas padrões de diagnóstico, que não me ajudaram muito 
# top
Foi o primeiro, para tentar identificar se havia alguma coisa sobrecarregando o
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
, nada de anormal, tudo dentro dos padrões.
# tail -f /var/log/messages
Para verificar as mensagens do sistema, nada de muito estranho...
Como é muito comum o MySql sair do ar quando o /tmp fica lotado, fui dar uma olhada na ocupação do mesmo pelo WHM, realmente estava bem alta.
# ls -la /tmp
O /tmp estava cheio de arquivos *.wrk e core.*.
os *.wrk, já eram velhos conhecidos, são gerados por um problema de compatibilidade entre o módulo GZip e o OpenSSL.
Os core.* são arquivos de [tag]Core[/tag] Dump, são gerados quando algum programa causa um problema grave e tem que ser encerrado a força para manter o sistema de pé (essa foi minha primeira dica do que poderia estar acontecendo).
Quando o programa apresenta tal falha, o
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
grava os dados que estão na parte da
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
usada pelo programa para um arquivo em
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
para poder ser analisado.
Eu só queria saber quem gerou o erro, não queria perder muito tempo.
# file core.124527
Esse comando me deu a dica de que o PHP estava gerando os core dumps.
Para resolver os *.wrk, foi simples, recompilei o Apache, removendo o módulo GZip.
Já os core.*, foi bastante complicado.
Eles estavam inundando o
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
do servidor, quase não dava para acessá-lo, então eu tinha que estancar esse problema, antes de resolver de vez.
A primeira coisa que fiz foi tentar limitar o tamanho dos arquivos core.*.
# ulimit -c 0
O comando acima dizia para o sistema limitar o tamanho dos arquivos core a 0 bytes, por algum motivo isso não resolveu plenamente, os arquivos ainda estavam sendo criados...
Nesse ponto a situação do HD já estava bastante critica e ai acabar sendo impossÃvel acessar o servidor por falta de espaço em disco.
Tive que limpar o HD antes de prosseguir:
# find / -name "core.[0-9]*" -print -exec rm -f {}\;
O comando acima procura por todos os core.algum_numero, lista na tela e o remove, a quantidade de arquivos listados foi absurda, isso me confirmou que só poderia ser o Apache ou o PHP que estavam gerando esses, como são os programas que mais disparam processos em um servidor
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
.
Alguns minutos depois, o HD já estava lotados desses arquivos novamente, estava realmente, complicado de tentar resolver o problema, enquanto o HD lotava sem parar.
O servidor estava dando um DoS nele mesmo :).
Para não ter que ficar rodando este comando toda hora, crie uma cron job para fazer isso por mim.
# crontab -e
Adicionei a linha, abaixo, no final do arquivo.
*/10 * * * * find / -name "core.[0-9]*" -exec rm -f {}\;
Essa linha informa ao servidor para rodar o comando a cada 10 minutos, salvei o arquivo e comecei a ter um pouco de descanso com relação ao espaço em disco, porém, por ser um processo pesado, o [tag]serverload[/tag] saltou para 59+, quando o normal (neste server) é ficar em torno de 0.6.
O servidor ficou extremamente lento, mas pelo menos eu poderia trabalhar para solucionar de vez o problema.
Pelo WHM, voltei a opção de recompilar o Apache e desmarquei a opção de não atualizar os pacotes que já estavam atualizados, ou seja, forcei que ele recompilasse todos os pacotes, só para garantir que não era um erro de compilação.
Nada feito, o problema continuou.
Comecei a pensar em todos os eventos que precederam o problema, para tentar descobrir a causa do mesmo, já tinha refeito todos os passos dos últimos dias, com exceção a atualização do Zend (que eu vim a descobrir depois que era o causador do problema).
Resolvi dar uma caçada pela internet por pessoas que estivessem com problemas parecido, já que a essa altura, não sabia mais o que fazer.
Encontrei no fórum do cPanel, uma pessoa reclamando que a versão 3.0 do Zend estava inundando o HD dele de core dumps.
Ótimo, estava matada a charada, agora eu tinha que fazer um downgrade da versão 3.0 para a 2.6.2 (última versão estável e confiável).
Os passos para o downgrade, foram:
# cd /scripts/
# pico installzendopt
Alterei a variável da versão para 2.6.2 e salvei o arquivo.
# ./installzendopt
Segui os passos do script de
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
e no final, estava com o Zend Opt na versão 2.6.2.
Foi como mágica, o sistema parou de gerar arquivos core.*.
O HD agora, tinha parado de ficar lotado, para diminuir o serverload, removi a cron job que apagava os
Compare Preços de: 24 horas, servidor, segurança, MySql, PHP, ferramentas, programa, HD, WHM
.
Finalmente o servidor tinha voltado ao normal e estava funcionando tudo como deveria ser, ufa!
Para garantir que não seja feita outra atualização automática do Zend opt até que eu tenha certeza que o problema foi resolvido, protegi o script de instalação contra escrita, assim só quando eu desproteger, pode ser colocada uma nova versão.
# chattr +i installzendopt
Depois dessa surra, tomei um copão de suco de maracujá que minha esposa fez para mim, precisava relaxar um pouco 
e comecei a desenvolver um plugin para o WP, que descreverei no próximo post.
Queria só fazer um comentário: Quando me perguntam se é necessário conhecer shell para administrar um servidor web e todos acham que estou exagerando quando falo que sim, é por causa de situações como essa.
No dia-a-dia, realmente, só o WHM dá conta de tudo, mas quando o bicho pega, só é possÃvel solucionar pelo shell.
Se eu não conhecesse bem o [tag]shell[/tag], teria morrido em US$ 75,00 por hora para solução do problema pelo suporte do Datacenter, levando em consideração que uma pessoa 100% dedicada a solucionar o caso levaria entre 6 e 10 horas deixar o server tinindo, esse problema teria me custado entre US$ 450,00 e US$ 750,00.
Então, se você pretende ter seu próprio servidor web, aprenda shell, pode lhe economizar muito dinheiro.
Abraços.
Artigos relacionados
- Retrospectiva 2006
- Nova Versão do Wordpress
- links for 2006-06-08
- links for 2006-05-19
- Você acompanha seu blog?
Eu percebi vários arquivos core.* quando fui acessar minha conta via ftp para fazer algumas alterações, então deletei eles, mas logo depois, quando atualizei a pasta, já tinha aparecido mais 4 arquivos no lugar o.0
Agora da pra perceber que ta 100%
Otimo trabalho Bruno
Obrigado, essa deu uma canseira, espero não encarar outra dessa tão cedo
Abraço