O log do servidor fica descontrolado e alguns serviços do sistema morrem até a reinicialização

1

A essência do nosso problema é que perdemos o acesso ssh ao nosso VPS e nossos arquivos de log se misturam. Fazer uma reinicialização por meio do console da Web do nosso provedor de hospedagem parece consertar as coisas, mas o problema se repete.

Mais detalhes

Isso parece ocorrer de maneira um tanto aleatória, aproximadamente uma vez a cada duas semanas. O sintoma que costumamos notar primeiro é que não podemos fazer login via ssh; Estranhamente, o servidor ainda nos pede uma senha, mas nunca nos permite efetuar o login. O Apache continua no transporte, mas outros serviços do sistema também morrem.

No momento dos "eventos de erro", recebemos uma tonelada de lixo de aparência aleatória em todos os nossos arquivos de log (tudo em / var / log, assim como os logs de host virtual do Apache e outros). O lixo contém muitos bytes nulos, algumas coisas de aparência binária de unicode, grandes blocos de ASCII aleatórios, partes de outros arquivos de log e css / javascript (veja os exemplos abaixo). Parece que está escrevendo o cache do buffer em arquivos abertos no momento, mas não tenho ideia de por que ou até mesmo como isso aconteceria. O Fedora usa o syslogd para o registro, mas não consegui encontrar nenhum problema óbvio lá.

Nosso servidor é um VPS executando o Fedora 12. Suas principais funções são executar o Apache, o Postfix e o ssh. Os sites que o Apache está usando usam PHP / MySQL (a última vez que isso aconteceu, eu instalei o patch Suhosin no caso de um ataque de estouro de buffer estranho ou algo assim).

Temos senhas seguras para nossos usuários ssh / htpasswd e os logs (as partes que podemos ler de qualquer maneira) não indicam que nosso servidor foi comprometido "por dentro".

Exemplo de Logfiles Borked

Aqui está um trecho do nosso log cron. Este tem um monte de bytes nulos e outros dados de aparência binária, mas como mencionado acima alguns outros arquivos contêm ASCII e / ou pedaços de outros arquivos:

Sep 23 03:05:01 HostName CROND[3208]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
Sep 23 03:05:01 HostName CROND[3209]: (user1) CMD (/path/to/development.domain.com/public/protected/yiic serverState)
Sep 23 03:10:01 HostName CROND[3792]: (root) CMD (/usr/lib64/sa/sa1 -S DISK 1 1)
Sep 23 03:10:01 HostName CROND[3795]: (user1) CMD (/path/to/development.domain.com/public/protected/yiic serverState)
Sep 23 03:10:01 HostName CROND[3793]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
Sep 23 03:15:01 HostName CROND[4414]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
Sep 23 03:15:01 HostName CROND[4415]: (user1) CMD (/path/to/development.domain.com/public/protected/yiic serverState)
Sep 23 03:20:01 HostName CROND[5000]: (root) CMD (/usr/lib64/sa/sa1 -S DISK 1 1)
Sep 23 03:20:01 HostName CROND[5001]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
Sep 23 03:20:01 HostName CROND[5003]: (user1) CMD (/path/to/development.domain.com/public/protected/yiic serverState)
Sep 23 03:25:01 HostName CROND[5590]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
Sep 23 03:25:01 HostName CROND[5591]: (user1) CMD (/path/to/development.domain.com/public/protected/yiic serverState)
Sep 23 03:30:01 HostName CROND[6175]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
Sep 23 03:30:01 HostName CROND[6174]: (root) CMD (/usr/lib64/sa/sa1 -S DISK 1 1)
Sep 23 03:30:01 HostName CROND[6176]: (user1) CMD (/path/to/development.domain.com/public/protected/yiic serverState)
Sep 23 03:35:01 HostName CROND[6763]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
Sep 23 03:35:01 HostName CROND[6764]: (user1) CMD (/path/to/development.domain.com/public/protected/yiic serverState)
Sep 23 03:40:01 HostName CROND[7347]: (root) CMD (/usr/lib64/sa/sa1 -S DISK 1 1)
Sep 23 03:40:01 HostName CROND[7349]: (munin) CMD (test -x /usr/bin/munin-cron && /usr/bin/munin-cron)
Sep 23 03:40:01 HostName CROND[7350]: (user1) CMD (/path/to/development.domain.com/public/protected/yiic serverState)
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^$


����.]������^[�Z��� ��H*[ݬ^T�՜^F�Ük֜�՜0�|��Ԝ0��5�֜+�^\J̜aMݺu3^]�'M��I�&�[�n^Vdz�&""^RȳZ�uݳݳʳ��۳g:h��;�5^U;k�j�C��Rj�C ^Zv��Ρġ^\֡T]]���2^@@aa!���Q^^nq�]v֛7oƚ5k'4^Z1^?�|^D^E^E!22^R���P�TX�n��aޚwbgM$
^KQ�����l4U�;���e��v�� 7u֯7oޯDVV^V j5������^O�Vk���5^Q^QI%���ͱ�α�ƍ^[�� ^O                    
por Matt Kantor 25.09.2010 / 00:38

2 respostas

2

Há muitas incógnitas nisso, mas estou pensando em falha no sistema de arquivos.

Um daemon em execução pode ter coisas suficientes armazenadas no cache para aceitar a conexão, mas não para concluir uma autenticação completa.

Os arquivos misturados são um strong indicador de que o sistema de arquivos (ou sua recuperação) está indo mal. Isso pode ser causado por software (kernel experimental / sistema de arquivos / ...) ou hardware. Estou inclinado a ir com o último. Execute uma verificação adequada do sistema de arquivos e um teste de hardware no disco (badblocks e, enquanto estiver fazendo isso, execute o memtest86, se puder).

Além disso, você deve considerar que o b0rking de arquivos pode não estar limitado a arquivos de log. Também poderia estar no código ou bancos de dados. Eu recomendo que você verifique se os dados são válidos em todos os lugares ...

    
por 26.09.2010 / 09:47
1

Até a parte sobre estranheza do sistema de arquivos, seus sintomas parecem ser exatamente os de ficar sem RAM. O SSH fornece um prompt, pois ele já está em execução, mas encontrar memória para gerar um novo processo é lento. E os serviços do sistema morrem porque são atingidos pelo OOM-killer. Há alguma referência a isso nos logs?

Você tem alguma métrica sobre o uso da memória ou a carga do sistema, preferencialmente gravada externamente na máquina problemática?

Seria extremamente útil ter registros remotos também - então você poderia ver se alguma pista vital está sendo sobrescrita pela corrupção do arquivo. O Fedora usa rsyslogd e o site rsyslog tem instruções sobre como configurar isso com segurança .

    
por 05.12.2010 / 16:11