El servidor cayÃ³ – hora del postmortem

Antes de la muerte sÃºbita, uno puede plantearse muchas cosas. A toro pasado, poco mÃ¡s que hacer un anÃ¡lisis forense…

Si tienes programadas alertas para posibles fallos, tu nagios (o equivalente) te habrÃ¡ avisado con antelaciÃ³n para prevenir la catÃ¡strofe. Si ademÃ¡s tienes montado algo mÃ¡s o menos altamente disponible, el impacto no suele ser tan grave (incluso aunque se caiga el servidor)

No obstante, en este artÃculo nos centraremos en la pregunta que se suelen hacer los usuarios en estos casos: «Â¿y por quÃ© se ha caido?». El administrador suele preguntarse algo mÃ¡s prÃ¡ctico: «Â¿cÃ³mo evitar que se repita?» (en ese servidor, y en el resto, por si acaso).

Si la consola permanece visible, los mensajes que aparecen pueden ser un buen punto de partida para el anÃ¡lisis forense.

Por defecto, los logs que suelen estar disponibles son kernel.log y auth.log. En ellos puede encontrarse alguna pista.

Si tienes instalado atop y/o snoopy, tendrÃ¡s algo mÃ¡s de informaciÃ³n.

Con kdump se puede obtener un volcado del nÃºcleo de Linux. Para ello hace falta que el kernel en uso estÃ© preparado («After successfully loading the dump-capture kernel as previously described, the system will reboot into the dump-capture kernel if a system crash is triggered»)

La preparaciÃ³n de kdump no es trivial. En Debian, el paquete kdump-tools ayuda con el proceso. Con netdump, se puede hacer el volcado en otro ordenador (via ssh)

No se puede descartar la posibilidad de que el fallo se deba al hardware (la memoria, la placa base y todo lo que integra…), a un calentamiento (que serÃa delatado por los registros de temperatura), fallos en servicios privilegiados (o en controladores)…

Las tarjetas grÃ¡ficas y las X pueden ser tambiÃ©n causa de conflicto, pero normalmente en los servidores no se instalan.