Detectar fallos de hardware (Parte 1) – Taller Linux
En esta semana en Taller Linux vamos a explicaros las formas más comunes de detectar fallos de hardware y como tratarlos en un servidor linux al cual no tenemos acceso físico. Primero para clarificar mejor vamos a definirlos en dos categorías. A los problemas que hacen que un sistema no esté online, es decir no tenemos acceso a los servicios o SSH los llamaremos de tipo A. Y las incidencias donde el sistema aun está online y podemos acceder por SSH, pero por ejemplo de vez en cuando se reinicia, o se caen servicios, etc.. a estos los llamaremos de tipo B.
Por tanto, ante cualquier problema el primer paso es intentar acceder como administrador al sistema por SSH y determinar de que tipo es. Si no podemos acceder será de tipo A y si entramos y nos deja ejecutar comandos lo pondremos de momento en el tipo B accutane price.
TIPO A (No podemos acceder)
Para los de tipo A lo primero que tenemos que hacer es tratar de reiniciar el servidor. La mayoría de proveedores permiten esto, e incluso algunos permiten hacer un soft reset (en caliente), donde se le indica al sistema operativo que debe reiniciarse. También, si el proveedor lo permite es mejor arrancar el sistema en un modo rescate que no use el disco duro, para poder hacer pruebas y revisarlo más detenidamente, luego explicaremos lo que se puede hacer en este modo.
En caso que al reiniciarlo o activar el modo rescate siga sin estar accesible por el puerto de administración, ya será necesario contactar con el soporte que tengamos en el centro de datos ya que por nuestra parte no hay nada mas que podamos hacer.
Respecto a los reinicios en frío nos gustaría comentar dos cosas, la primera es que no hay que abusar de ellos porque son perjudiciales para el hardware. Suponen un corte en la alimentación de los dispositivos utilizados y esto puede generar más problemas, normalmente en discos duros pero también en el resto. Lo segundo es que al reiniciar un sistema linux, si este llevaba mucho tiempo encendido, es posible que necesite chequear automáticamente la estructura de ficheros en los discos y el arranque tarde un tiempo en completarse. Por tanto si se ha reiniciado de forma normal (no en modo rescate) habrá que esperar al menos de 30 a 60 minutos de inactividad para contactar con el soporte del proveedor. Por esto siempre es mejor arrancarlo en modo rescate si se tiene la posibilidad.
TIPO B (Podemos acceder)
Si por el contrario podemos acceder, estamos ante un problema tipo B que puede o no ser de hardware, aun tendremos que determinarlo. Cosas que podemos hacer:
- Ver si ha quedado registrado algún error.
Para ello debemos ver las entradas sospechosas en el log del sistema, que suele ser el fichero /var/log/syslog o /var/log/messages. Lo normal es buscar por fecha y hora sabiendo cuando ha empezado el problema que nos ha llevado hasta aquí.
Si no sabemos con exactitud cuando buscar podemos filtrar por la palabra error, por ejemplo:
grep -i error /var/log/messages
Y aquí nos tendría que salir alguna cosa para determinar de donde proviene el fallo,
- Utilizar SMART para buscar errores en los discos duros
Si los discos duros soportan la tecnología SMART es posible ver su estado de forma muy fácil, utilizando el comando:
smartctl -a /dev/dispositivo
- Visualizar los sensores de temperatura, rpm y demás que haya configurados en el sistema.
Para ello podemos instalar la aplicación lm-sensors que suele estar en los repositorios de las distribuciones más usadas.
Si con todo esto seguimos sin detectar que puede estar sucediendo convendría arrancar el sistema en modo rescate o de alguna forma que nos permita desmontar el disco duro y revisarlo a fondo sin todos los servicios en funcionamiento. Esto lo dejaremos para la segunda parte de este taller linux sobre como detectar fallos de hardware..
Un saludo
