Troubleshooting: guía de resolución de problemas en sistemas GNU / Linux – Parte 1/3

Hay una cosa que desespera más que un problema técnico en un sistema informático, y eso es la incertidumbre de no saber el origen de dicho problema. Por eso, es importante trazar un plan para poder identificar la fuente del fallo y poder actuar para solventar el problema. Pero, para eso, es necesario conocer algunas herramientas y registros claves que se pueden emplear en sistemas GNU/Linux en estos casos.

En esta guía intentaré mostrar los pasos esenciales para poder comenzar a diagnosticar problemas y cómo se debería proceder para reparar el sistema…

*Nota: no se trata de listar todos los posibles problemas, su diagnóstico y reparación, ya que sería casi imposible. Simplemente pretendo dar una forma de proceder para que puedas aplicarlo en cualquier caso, sea cual sea el origen del problema.

Consejos iniciales para la reparación de sistemas

Aunque veas este apartado estúpido, es probable que sea el apartado que más te pueda ayudar en el día a día cuando te enfrentas a los problemas:

• No obcecarse: si lo haces, eso puede hacer que tengas el problema delante, pero que no logres verlo con claridad. Es más, si llevas mucho tiempo tratando de encontrar la causa del problema, te recomendaría que te tomes un descanso. A veces eso puede hacer que lo que se vuelva evidente y puedas resolverlo rápidamente. ¡Quizás este sea el mejor consejo que te pueda dar!
• De lo más banal a lo más profundo: a veces se comienza a probar cosas sin orden lógico, lo que puede terminar con un mal diagnóstico que te lleve a realizar alguna operación para reparar que puede ser más costosa en tiempo o recursos. Por ejemplo, sustituir un componente cuando el problema era algo superfluo. Por ejemplo, imagina que no puedes imprimir. Podrías comenzar a comprobar drivers, si el software con el que estás tratando de enviar el documento a la cola de impresión funciona, etc., pero tal vez el problema sea mucho más simple que eso. ¿Has puesto papel en la bandeja de entrada de tu impresora? Lo que intento decir es que, en ocasiones, son cosas muy simples y no las ves, lanzándote a realizar tareas complejas que no tienen sentido. En este caso, lo ideal sería:
  1. ¿La impresora está enchufada?
  2. ¿Está encendida?
  3. ¿Hay papel? ¿Estado de los consumibles?
  4. ¿Hay algún tipo de atasco?
  5. ¿La conexión de datos es correcta?
  6. ¿Están instalados los controladores?
  7. ¿Es un problema del software?
  8. ¿Es el hardware de la impresora?

• Conocer el sistema: tener conocimientos, al menos básicos, sobre el sistema operativo, o la arquitectura de hardware, es vital. Eso te puede hacer tener una idea mucho más clara de dónde puede estar el problema y agilizará el proceso, junto con el consejo del punto anterior. Por ejemplo, observa estas imágenes que he creado y que muestra muy bien el por qué de tener conocimiento del sistema (en este caso sobre la pila de sonido):

• Usa todos tus sentidos: para el diagnóstico deberías poner todos tus sentidos (menos uno) alerta. Es importante que:
  • Visión: mensajes de error, comportamientos extraños, LEDs, daños físicos, etc.
  • Olfato: olores a quemado extraños.
  • Audición: beep codes, sonidos extraños de algunas unidades (especialmente discos duros mecánicos), explosiones de condensadores, rozamiento,…
  • Tacto: comprobar que las conexiones están bien, sensación de calor excesivo en algunas zonas, etc.
• Ser sistemático: esto viene a complementar a los puntos anteriores. Y los pasos esenciales para un buen proceso de diagnóstico y reparación son:
  1. Diagnosticar el origen del problema. Es decir, encontrar los códigos de error, los indicadores LEDs, etc.
  2. Analizar la situación para comprender lo que ocurre.
  3. Acotar, realizando pruebas para demostrar que ciertamente es ese el fallo y no otro.
  4. Solucionar, trazando un plan de actuación para resolver el problema.
  5. Experiencia, un paso que se olvida y que es muy importante. No para dicho fallo que ya ha sido resuelto, pero sí para evitar futuros fallos similares con lo aprendido de esta lección.
• Dótate de las herramientas necesarias: siempre deberías conocer y tener a mano las herramientas necesarias para un buen diagnóstico y reparación. Pueden ser desde herramientas físicas (multímetro, termómetro o cámara termograica,…), hasta otras de software (de información, tests, bechmarks, debugging, networking, escáner de malware,…), pasando por otras de recuperación o prevención (backups, restauración, recuperación de datos,…).
• Consultar manuales y documentación: tener la documentación (datasheets, wikis, README, HOWTO, man) de los dispositivos y software que usas es de gran ayuda, ya que podrás comprobar algunos errores frecuentes que están documentados. Ya sabes… RTFM (Read The Fucking Manual).
• Internet: en la red existen multitud de foros y páginas donde poder encontrar información de errores o de problemas por conocidos, así como las posibles soluciones. Así que, no olvides usar este recurso.
• Simplicidad: aunque esto no sirva para solventar problemas, sí que es práctico para evitar muchos de ellos. Recuerda que mientras más sencillo (véase principio KISS) sea un sistema o dispositivo (menos partes, servicios, etc.), más fiable será.

Tipos de fallos

Para la reparación de posibles problemas, también es importante tener muy claro los diferentes tipos de fallos con los que te puedes encontrar:

• Software: son todos aquellos cuyo origen proviene del software:
  • Inicio: aquellos que afectan al arranque del sistema y evitan que se inicie la sesión o que lo hacen de una forma anómala. Suelen estar causados por el gestor de arranque, problemas en las particiones de arranque, por el propio sistema operativo, el sector MBR/GPT, etc.
  • Sistema operativo: son aquellos específicos que afectan al propio kernel o a otros sistemas auxiliares del SO. Destacan:
    • Kernel oops: se trata de un soft panic, un fallo tras el cuál el sistema sigue funcionando tras haber matado al proceso que generó la infracción. En algunos casos podría ser necesario reiniciar si el problema está afectando a un subsistema importante. Incluso podría ocurrir que el kernel oops termina colapsando al sistema y produzca un kernel panic. En cuanto a las causas:
      • Capacidad del medio de almacenamiento agotada.
      • Memoria principal insuficiente.
      • Incompatibilidades.
      • Corrupción de datos.
      • Errores.
    • Kernel Panic: es el equivalente a los BSOD (Blue Screen of Deat) de Windows. Y se trata de un hard panic, uno de los peores fallos que puede sufrir. Generalmente el sistema dejará de funcionar y se mostrará un mensaje de error en la pantalla. No se puede recuperar el sistema, cesa la actividad y se produce un reinicio. Su nombre proviene de la syscall panic() que se usa en entornos *nix. Esa llamada al sistema tiene como objetivo enviar un mensaje de error a la consola y realizar un volcado de la memoria principal a la secundaria (KCD o Kernel Crash Dump) para un depurado. En cuanto a las posibles causas:
      • Intento fallido al leer una dirección de memoria inválida o de acceso restringido.
      • Problemas en los controladores esenciales.
      • Mala configuración del kernel o una mala compilación de éste.
      • Errores fatales durante el inicio al no encontrarse un módulo, controlador, o partición raíz.
      • Explotación de una vulnerabilidad, presencia de un bug.
      • Problemas con la memoria RAM.
      • Fallo del proceso init.
      • Problemas con el initramfs.
      • Kernel mal instalado, o no soportado.
      • Parches instalados que hayan agregado alguna falla.
    • Otros: también puede haber otros errores menores que suceden de forma transparente durante el inicio o el uso. Suelen registrarse en el registro, o mostrarse durante el inicio, y los mensajes son bastante esclarecedores de lo que ha causado el error. Pero no suelen tener tanta importancia y permiten que el sistema funcione.
  • Controladores/firmware: aunque esto podría haberse integrado en el punto anterior, ya que los controladores se integran como parte del kernel o en módulos de éste, lo he apartado. Se trata de unos problemas muy particulares que generalmente causan que un componente de hardware no funcione adecuadamente o que no lo haga en absoluto. (puedes probar FWTS (Fimware Test Suite) como herramienta para realizar pruebas al firmware y detectar problemas)
  • Programas: aquí se incluyen tanto las apps que se usan habitualmente, los scripts, así como los programas para implementar servicios. No solo por problemas causados por vulnerabilidades, bugs, dependencias de paquetes o bibliotecas, incompatibilidad, etc., también por competencia/acaparamiento de recursos (procesos zombie, malware,…), etc.
• Hardware: se deben a fallos de origen físico.:
  • Problemas en las conexiones: cables mal conectados o en mal estado, puertos rotos, circuitos abiertos, etc.
  • Problemas electrónicos: daños en la circuitería de algún componente, humedad, sobrecalentamiento, suciedad,…
  • Conflictos: es posible que pueda haber incompatibilidades, o conflictos entre componentes. Generalmente por uso de IRQs, canales DMA, etc.
  • Problemas de rendimiento y recursos: cuando se produce throttiling por exceso de temperatura, memoria insuficiente, necesidad de mejorar el rendimiento de computo, etc.

Niveles para los logs en Linux

También es importante conocer los niveles que existen a la hora de registrar mensajes en los logs de Linux. Cada uno implica un nivel de importancia diferente y pueden indicarte si estás ante un error sin importancia o algo más grave:

Con grep y usando una tubería podrías filtrar el contenido de los logs en texto plano por nivel. Para los binarios, las herramientas de systemd también tienen sus opciones para filtrar…

• Nivel 0 (Kern_emerg): es un error de alto grado de severidad, una emergencia que puede generar crashes o inestabilidad.
• Nivel 1 (Kern_alert): es una alerta que indica que se necesita atención inmediata, ya que puede ser grave, afectando al funcionamiento del sistema o subsistemas.
• Nivel 2 (Kern_crit): un nivel también bastante severo, un error crítico que puede implicar problemas de hardware o software graves.
• Nivel 3 (Kern_err): es un error no crítico, y puede estar relacionado con problemas al reconocer un dispositivo por los controladores, etc.
• Nivel 4 (Kern_warning): es una advertencia, usada para indicar ciertos errores de menor importancia.
• Nivel 5 (Kern_notice): eventos que quizás puedan ser problemáticos y son dignos de mención.
• Nivel 6 (Kern_info): informa de acciones o eventos realizados por el kernel.
• Nivel 7 (Kern_debug): es usado para la depuración.