Introducción

Algunos servicios de Linux están diseñados para salir tras la inicialización — y eso confunde a los monitores de servicio. Si estás supervisando uno de estos con un monitor de servicio en Level, recibirás alertas falsas. La solución es un monitor de script que lee SubState en lugar de ActiveState.

Por qué los monitores de servicio generan alertas falsas

systemd rastrea cada unidad a través de dos campos de estado: ActiveState y SubState. Los monitores de servicio comprueban ActiveState — valores como active, inactive, o failed.

El problema: ciertos servicios salen después de realizar su tarea y nunca entran en un estado active estado. El wg-quick es el ejemplo más común. Configura la interfaz VPN y luego sale. systemd registra ActiveState como inactive (exited). Un monitor de servicio detecta inactive y genera una alerta — aunque la VPN esté funcionando correctamente, la interfaz esté activa y el tráfico esté enrutando.

SubState cuenta una historia más precisa. Para servicios como wg-quick, un SubState saludable es exited — esperado y normal. Un SubState de failed significaría que algo salió realmente mal. Comprobar SubState directamente es lo que permite distinguir la diferencia.

Comprobar SubState con un script

Usar systemctl show para leer el SubState de cualquier unidad:

systemctl show -p SubState --value <unit_name>

Esto devuelve una cadena de texto simple — running, exited, dead, failed, etc. — que puedes evaluar en un monitor de script.

🖥️ NOTA DE PLATAFORMA:

Linux: Compatible con cualquier distribución que use systemd.
Windows / macOS: No aplicable. systemctl es solo para Linux.

Ejemplo: Monitorización de una interfaz WireGuard

El script siguiente comprueba si wg-quick@wg0 está en el exited SubState. Sustituye por el nombre real de tu unidad si es diferente.

#!/bin/bash

UNIT_NAME="wg-quick@wg0"
STATUS=$(systemctl show -p SubState --value $UNIT_NAME)

if [ "$STATUS" = "exited" ]; then
    echo "Service is running correctly."
    exit 0
else
    echo "ALERT: Service is not running. SubState: $STATUS"
    exit 1
fi

El script produce una cadena de estado legible y sale con código 0 (saludable) o 1 (estado inesperado). Configura el monitor de script para que se active cuando la salida Contiene la cadena de fallo «ALERT».

Configuración del monitor:

Campo	Valor
Tipo	Ejecutar script
SO	Linux
Script	Linux - Comprobación de SubState de WireGuard
Salida del script	Contiene
Valor	`ALERT`
Frecuencia de ejecución	5 minutos
Número de activaciones	2

💡 CONSEJO: Establece Número de activaciones a 2 o más para evitar alertas por estados transitorios durante reinicios del servicio o del sistema.

Otros tipos de unidades que salen por diseño

wg-quick es el caso más común, pero cualquiera de estos puede desencadenar el mismo patrón de alertas falsas:

Servicios oneshot — ejecutan una tarea y salen; SubState será exited cuando está en buen estado
Unidades de temporizador — se ejecutan según una programación; comprueba ActiveState para la propia unidad de temporizador, no el servicio que lanza
Servicios Type=forking — el proceso padre sale tras lanzar un proceso hijo; el SubState puede ser exited mientras se ejecuta el proceso hijo

Para todos estos, un monitor de script que comprueba SubState con tu valor conocido como correcto es el enfoque adecuado.

Preguntas frecuentes

Mi servicio WireGuard aparece como caído en Level pero el tráfico está enrutando correctamente. ¿Qué está pasando? wg-quick sale después de configurar la interfaz VPN — eso es normal. La interfaz de red permanece activa aunque el proceso del servicio haya salido. Un monitor de servicio detecta inactive y genera una alerta. Usa un monitor de script que compruebe SubState (que devuelve exited, el valor saludable) en su lugar.
¿Cómo sé qué valor de SubState esperar cuando un servicio está en buen estado? Ejecuta systemctl show -p SubState --value <unit_name> en un dispositivo donde el servicio funciona correctamente. Lo que devuelva será tu valor base saludable. Escribe el script usando ese valor.
¿Puedo comprobar tanto ActiveState como SubState en el mismo monitor? Sí. Escribe el script para leer ambos y que falle si alguno es inesperado. Esto te da una cobertura más amplia — puedes detectar servicios que salieron inesperadamente (SubState: failed) por separado de los servicios que simplemente están detenidos (ActiveState: inactive).
¿Esto funciona en distribuciones de Linux que no usan systemd? No. systemctl requiere systemd. En distribuciones que usan SysVinit o Upstart, necesitarías herramientas diferentes (p. ej., service <name> status). La mayoría de las distribuciones de Linux con mantenimiento activo incluyen systemd.

Monitorización de archivos de unidad systemd en Linux