Eu tenho cerca de uma dúzia de computadores de placa única em uma rede executando o Debian (squeeze) e os acesso via ssh (o servidor ssh é dropbear). Para se ter uma ideia do hardware desses computadores, eles são processadores x86 de 1,2 GHz, 1 GB de RAM e unidades flash de 4 GB formatadas como ext2 (evitei o ext3 para evitar o estresse adicional de gravação do flash no diário), há também uma partição swap em a unidade.
Normalmente a configuração que estou usando funciona muito bem e consigo acessar todos os computadores. De vez em quando um impedirá o acesso. O que acontece é que tento me conectar via ssh (putty) e ele me dá o prompt de login, insiro o nome de usuário e a senha e ele responde 'Acesso negado' e também recusa qualquer chave pública em ~/.ssh/authorized_keys. As credenciais estão corretas, pois funcionavam anteriormente. O computador responde aos pings e o PuTTY reconhece a chave pública do servidor, o que implica para mim que o sistema ainda está em execução. Reiniciar o servidor resolve o problema e posso fazer login novamente. (Eu tentei uma correção temporária de colocar shutdown -r now no crontab raiz, mas isso não parece ser executado de forma confiável quando o travamento acontece) Depois de reiniciar, no entanto, não parece haver nenhuma informação em nenhum dos logs do sistema para indicar o que aconteceu, os logs ficam simplesmente vazios naquele período de tempo, como se o sistema tivesse travado.
Há algum software personalizado em execução no sistema que parece parar de funcionar (é por isso que eu queria fazer o ssh para começar). Presumo que este programa seja a origem dos problemas, mas não tenho certeza de como isso causaria e como depurar o que está acontecendo.
A explicação mais provável que posso imaginar é que há um vazamento de memória no outro programa que impede o dropbear de gerar um novo shell de login (e o crontab de executar o desligamento), pois não há memória livre suficiente. Mas olhando para o uso de memória dos outros computadores (em funcionamento), não parece haver nenhum aumento significativo na memória para indicar um vazamento (a menos que seja um vazamento muito grande, de ação rápida e raro). Eu pensaria que quando o sistema operacional ficasse sem memória, ele reiniciaria o sistema ou mataria processos (o kernel do Linux reinicia, certo?). A outra coisa que me pergunto é se o fato de eles estarem rodando em uma unidade flash poderia ter algum efeito, especialmente a partição swap (que acho que deveria remover para evitar o desgaste da unidade flash), mas as unidades flash são jovens (~ 1 mês) e não acho que esse desgaste seja um fator ainda.
Alguém tem uma idéia do que poderia causar esses sintomas, se isso poderia ser causado por um vazamento de memória ou por algo mais que não tenha pensado. E alguém conhece um método para tentar depurar o problema e descobrir mais informações sobre o que está errado?
Responder1
Acontece que o problema tinha algo a ver com as unidades flash específicas que eu estava usando. Eles tinham esse lixo especial 'U3' que aparentemente pode causar problemas no Linux se não for completamente desinstalado. Decidi que seria melhor mudar para uma instalação do tipo mais 'ao vivo' de qualquer maneira. Agora transfiro o sistema de arquivos raiz para a memória RAM na inicialização e executo a partir dele para que a unidade flash não seja crítica para o sistema continuar funcionando.