Tengo aproximadamente una docena de computadoras de placa única en una red que ejecuta Debian (squeeze) y accedo a ellas a través de ssh (el servidor ssh es dropbear). Para dar una idea del hardware de estas computadoras, son procesadores x86 de 1,2 GHz, 1 GB de RAM y unidades flash de 4 GB formateadas como ext2 (evité ext3 para evitar el estrés adicional de escritura flash al registrar en el diario), también hay una partición de intercambio en la unidad.
Normalmente la configuración que estoy usando funciona muy bien y puedo acceder a todas las computadoras. De vez en cuando alguno impedirá el acceso. Lo que sucede es que intento conectarme a través de ssh (putty) y me aparece el mensaje de inicio de sesión, ingreso el nombre de usuario y la contraseña y responde "Acceso denegado" y también rechazará cualquier clave pública en ~/.ssh/authorized_keys. Las credenciales son correctas tal como funcionaban anteriormente. La computadora responde a los pings y PuTTY reconoce la clave pública del servidor, lo que para mí implica que el sistema todavía está funcionando. Reiniciar el servidor soluciona el problema y puedo iniciar sesión nuevamente. (Probé una solución temporal al poner apagado -r ahora en el crontab raíz, pero no parece ejecutarse de manera confiable una vez que ocurre el bloqueo) Sin embargo, una vez que reinicio, no parece haber ninguna información en ninguno de los registros del sistema. para indicar lo que sucedió, los registros simplemente están vacíos para ese período de tiempo, como si el sistema hubiera fallado.
Hay algún software personalizado ejecutándose en el sistema que parece dejar de funcionar (razón por la cual quería iniciar con ssh). Supongo que este programa es la fuente de los problemas, pero no estoy seguro de cómo los causaría ni de cómo depurar lo que está sucediendo.
La explicación más probable que se me ocurre es que hay una pérdida de memoria en el otro programa que luego impide que dropbear genere un nuevo shell de inicio de sesión (y que crontab ejecute el apagado) ya que no hay suficiente memoria libre. Pero al observar el uso de la memoria de las otras computadoras (en funcionamiento), no parece haber ningún aumento significativo en la memoria que indique una fuga (a menos que sea una fuga muy grande, de acción rápida y poco común). Pensaría que cuando el sistema operativo se quedara sin memoria, reiniciaría el sistema o cerraría procesos (el kernel de Linux se reinicia, ¿verdad?). La otra cosa que me pregunto es si el hecho de que se estén ejecutando desde una unidad flash podría tener algún efecto, especialmente la partición de intercambio (que creo que debería eliminar para evitar el desgaste de la memoria flash), pero las unidades flash son jóvenes (~ 1 mes) y no creo que el desgaste sea un factor todavía.
¿Alguien tiene una idea de qué podría causar estos síntomas, si podría deberse a una pérdida de memoria o algo más en lo que no he pensado? ¿Y alguien conoce algún método para intentar solucionar el problema y encontrar más información sobre lo que está fallando?
Respuesta1
Resulta que el problema tenía algo que ver con las unidades flash específicas que estaba usando. Tenían esta basura especial 'U3' que aparentemente puede causar problemas en Linux si no se desinstala por completo. Decidí que sería mejor cambiar a una instalación de tipo más "en vivo" de todos modos. Ahora transfiero el sistema de archivos raíz a la RAM durante el arranque y lo ejecuto desde allí para que la unidad flash no sea crítica para que el sistema continúe ejecutándose.