Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Solución de problemas de fallos en servicios de Systemd: Una guía paso a paso

¿Tiene fallos en servicios de systemd? Esta guía completa proporciona un enfoque paso a paso para diagnosticar y resolver problemas comunes de inicio. Aprenda a utilizar `systemctl status` y `journalctl` para el análisis de registros, inspeccione meticulosamente los archivos de unidad en busca de configuraciones erróneas, identifique y corrija problemas de dependencias, y solucione problemas de variables de entorno. Con ejemplos prácticos y consejos avanzados, ganará la confianza para que sus servicios de Linux vuelvan a estar en línea de forma rápida y eficiente.

42 vistas

Solución de problemas de fallos en servicios Systemd: Una guía paso a paso

Systemd se ha convertido en el gestor de sistema y servicios de facto para la mayoría de las distribuciones modernas de Linux, desempeñando un papel crítico en la gestión de servicios, demonios y procesos. Aunque potentes y eficientes, los servicios gestionados por systemd a veces pueden fallar al iniciarse, lo que provoca tiempos de inactividad de las aplicaciones o inestabilidad del sistema. Diagnosticar estos fallos requiere un enfoque sistemático, aprovechando las sólidas capacidades de registro e introspección de systemd.

Esta guía proporciona una metodología completa y paso a paso para solucionar problemas comunes de inicio de servicios systemd. Cubriremos desde las comprobaciones de estado iniciales y la inmersión profunda en los registros hasta la inspección de archivos de unidad y la resolución de problemas complejos de dependencias. Al final de este artículo, tendrá el conocimiento práctico y las herramientas para diagnosticar y resolver eficientemente la mayoría de los fallos de servicios systemd, asegurando que sus aplicaciones y servicios funcionen sin problemas.

La primera línea de defensa: systemctl status

Cuando un servicio no se inicia, el primer comando que debe ejecutar es systemctl status <nombre_del_servicio>. Este comando proporciona una instantánea del estado actual del servicio, incluyendo si está activo, cargado y, lo que es crucial, un fragmento de sus registros recientes. Esto a menudo proporciona suficiente información para identificar rápidamente el problema.

Supongamos que su servicio de aplicación web, mywebapp.service, no se inicia:

systemctl status mywebapp.service

Interpretación del resultado de ejemplo:

● mywebapp.service - My Web Application
     Loaded: loaded (/etc/systemd/system/mywebapp.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Mon 2023-10-26 10:30:05 UTC; 10s ago
    Process: 12345 ExecStart=/usr/local/bin/mywebapp-start.sh (code=exited, status=1/FAILURE)
   Main PID: 12345 (code=exited, status=1/FAILURE)
        CPU: 10ms

Oct 26 10:30:05 hostname systemd[1]: Started My Web Application.
Oct 26 10:30:05 hostname mywebapp-start.sh[12345]: Error: Port 8080 already in use
Oct 26 10:30:05 hostname systemd[1]: mywebapp.service: Main process exited, code=exited, status=1/FAILURE
Oct 26 10:30:05 hostname systemd[1]: mywebapp.service: Failed with result 'exit-code'.

De este resultado, podemos ver inmediatamente:
* El servicio mywebapp.service ha fallado.
* Falló con Result: exit-code, lo que significa que el comando ExecStart salió con un estado distinto de cero.
* La línea Process muestra que el comando mywebapp-start.sh falló con status=1/FAILURE.
* Crucialmente, las líneas de registro indican: Error: Port 8080 already in use. Este es un claro indicador del problema.

Este comando es su primera herramienta de diagnóstico, a menudo señalando directamente la causa o reduciendo el lugar donde buscar a continuación.

Profundizando con journalctl

Aunque systemctl status proporciona un resumen rápido, journalctl es el comando al que debe recurrir para obtener un registro detallado. Consulta el journal de systemd, que recopila registros de todas las partes del sistema, incluidos los servicios.

Revisión básica de registros

Para ver todos los registros de un servicio específico, incluidas las entradas históricas:

journalctl -u mywebapp.service

Esto mostrará todas las entradas de registro asociadas con mywebapp.service. Si el servicio falla repetidamente, verá entradas de cada intento fallido.

Filtrado y consultas basadas en tiempo

Para acotar los resultados, especialmente después de un fallo reciente, puede utilizar indicadores como --since y --priority:

  • Mostrar registros desde un momento específico:
    bash journalctl -u mywebapp.service --since "10 minutes ago" journalctl -u mywebapp.service --since "2023-10-26 10:00:00"
  • Mostrar solo mensajes de nivel de error o superior:
    bash journalctl -u mywebapp.service -p err
  • Combinar con -xe para una explicación extendida y salida verbosa:
    bash journalctl -u mywebapp.service -xe --since "5 minutes ago"
    Esto es increíblemente útil, ya que journalctl -xe proporciona contexto adicional, incluyendo explicaciones para ciertos mensajes de registro y rastreos de pila si están disponibles.

Entendiendo los mensajes de registro

Busque palabras clave como Error, Failed, Warning o mensajes específicos de la aplicación que indiquen qué salió mal. Preste atención a las marcas de tiempo para comprender la secuencia de eventos que llevaron al fallo.

Consejo: Si el script ExecStart de su servicio imprime en la salida estándar o en el error estándar, esos mensajes suelen ser capturados por journalctl. Asegúrese de que sus scripts registren mensajes de error descriptivos.

Inspeccionando el archivo de unidad: El plano de su servicio

Cada servicio de systemd se define mediante un archivo de unidad (por ejemplo, mywebapp.service). Las configuraciones erróneas en este archivo son una fuente común de fallos de inicio. Necesita entender lo que el servicio intenta hacer.

Recuperando el archivo de unidad

Para ver el archivo de unidad activo de su servicio:

systemctl cat mywebapp.service

Este comando muestra el archivo de unidad exacto que está utilizando systemd, incluidas las anulaciones.

Directivas clave a verificar

Concéntrese en la sección [Service] para problemas relacionados con la ejecución y en [Unit] para las dependencias.

  • ExecStart: Este es el comando que systemd ejecuta para iniciar su servicio. Verifique que la ruta sea correcta y que el comando en sí sea ejecutable y se ejecute correctamente cuando se invoca manualmente (por ejemplo, como el User especificado).
    ini ExecStart=/usr/local/bin/mywebapp-start.sh
  • Type: Define el tipo de inicio del proceso. Los tipos comunes incluyen:
    • simple (predeterminado): ExecStart es el proceso principal.
    • forking: ExecStart bifurca un proceso hijo y el padre sale. Systemd espera a que el padre salga.
    • oneshot: ExecStart se ejecuta y sale; systemd considera que el servicio está activo mientras el comando se esté ejecutando.
    • notify: El servicio envía una notificación a systemd cuando está listo.
    • Un Type incorrecto puede llevar a que systemd piense que un servicio falló cuando en realidad se inició, o viceversa.
  • User / Group: El usuario y grupo bajo los cuales se ejecutará el servicio. Los problemas de permisos a menudo se derivan de que el servicio intenta acceder a archivos o recursos para los que no tiene derechos bajo este usuario.
    ini User=mywebappuser Group=mywebappgroup
  • WorkingDirectory: El directorio desde el cual se ejecutará el servicio. Las rutas relativas en ExecStart u otros comandos dependen de esto.
  • Restart: Define cuándo debe reiniciarse el servicio. Si se establece en on-failure o always, un servicio que falla podría reiniciarse constantemente, lo que dificulta la detección del fallo inicial.
  • TimeoutStartSec / TimeoutStopSec: Cuánto tiempo espera systemd a que el servicio se inicie o se detenga. Si un servicio tarda más en inicializarse que TimeoutStartSec, systemd lo eliminará e informará de un fallo.

Problemas comunes con los archivos de unidad

  • Rutas incorrectas: Error tipográfico en ExecStart u otras rutas de archivos.
  • Variables de Environment faltantes: Los servicios a menudo requieren variables de entorno específicas (por ejemplo, PATH) que podrían no estar presentes en el entorno limpio de systemd (ver más abajo).
  • Permisos: El User especificado no tiene permisos de ejecución para el script o permisos de lectura/escritura para los archivos de datos necesarios.
  • Errores de sintaxis: Errores tipográficos simples en el propio archivo de unidad.

Para probar ExecStart manualmente:

Cambie al usuario del servicio e intente ejecutar el comando directamente:

sudo -u mywebappuser /usr/local/bin/mywebapp-start.sh

Esto a menudo reproduce el error visto en journalctl directamente en su terminal, facilitando la depuración.

Gestión de dependencias: Cuando los servicios no pueden iniciarse solos

Los servicios a menudo dependen de otros servicios o componentes del sistema para estar activos antes de poder iniciarse. Systemd utiliza las directivas Wants, Requires, After y Before para gestionar estas dependencias.

Identificando dependencias

Utilice systemctl list-dependencies <nombre_del_servicio> para ver lo que un servicio requiere o desea ejecutar explícitamente.

systemctl list-dependencies mywebapp.service

Directivas comunes en la sección [Unit]:

  • After=: Especifica que este servicio debe iniciarse después de las unidades listadas. Si la unidad listada falla, este servicio aún intentará iniciarse (a menos que también se use Requires=).
  • Requires=: Especifica que este servicio requiere las unidades listadas. Si alguna de las unidades requeridas no se inicia, este servicio no se iniciará.
  • Wants=: Una forma más débil de Requires=. Si una unidad deseada falla, este servicio aún intentará iniciarse.

Ejemplo:

[Unit]
Description=My Web Application
After=network.target mysql.service
Requires=mysql.service

Aquí, mywebapp.service solo se iniciará después de que network.target y mysql.service se hayan iniciado, y requiere que mysql.service sea exitoso. Si mysql.service falla, mywebapp.service no se iniciará.

Resolviendo conflictos de dependencias

Si un servicio falla debido a un problema de dependencia, journalctl generalmente indicará qué dependencia no se pudo cumplir. Por ejemplo, podría indicar Dependency failed for My Web Application seguido de detalles sobre el fallo de mysql.service.

Pasos para resolver:
1. Verifique el servicio dependiente: Ejecute systemctl status <servicio_dependiente> (por ejemplo, systemctl status mysql.service) y journalctl -u <servicio_dependiente> para solucionar su fallo primero.
2. Verifique las directivas After= y Requires=: Asegúrese de que reflejen correctamente el orden de inicio deseado y la estrictez. A veces, un servicio necesita esperar a que un puerto específico esté abierto, no solo a que el servicio esté activo. Para casos complejos, systemd-socket-activate o scripts personalizados ExecStartPre pueden ser útiles.

Variables de entorno y rutas: Las trampas ocultas

Los servicios de Systemd se ejecutan en un entorno muy limpio y minimalista. Esto a menudo conduce a problemas en los que los comandos que funcionan perfectamente en el shell de un usuario fallan cuando son ejecutados por systemd porque faltan variables de entorno cruciales (como PATH).

El entorno limpio de Systemd

Cuando systemd inicia un servicio, no hereda el entorno completo del usuario que inició systemctl start. La variable PATH, por ejemplo, a menudo se reduce, lo que significa que comandos como python o node podrían no encontrarse si no están en ubicaciones estándar como /usr/bin o /bin.

Síntoma: ExecStart=/usr/local/bin/myscript.sh falla con "