Introducción

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

Por qué los monitores de servicios generan alertas falsas

systemd rastrea cada unidad en dos campos de estado: ActiveState y SubState. Los monitores de servicios comprueban ActiveState — valores como active, inactive, o failed.

El problema: ciertos servicios salen después de realizar su trabajo 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 servicios detecta inactive y dispara una alerta — aunque la VPN funcione correctamente, la interfaz esté activa y el tráfico se 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ó mal realmente. Comprobar SubState directamente es lo que te permite distinguirlos.

Comprobar el SubState con un script

Usa 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 exclusivo de Linux.

Ejemplo: Monitorización de una interfaz WireGuard

El script a continuación comprueba si wg-quick@wg0 se encuentra 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 genera una cadena de estado legible y sale con el 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
Recuento de activaciones	2

💡 CONSEJO: Establece Recuento 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á saludable
Unidades de temporizador — se ejecutan según un programa; comprueba ActiveState para la propia unidad de temporizador, no el servicio que lanza
Servicios Type=forking — el proceso padre sale tras crear un proceso hijo; el SubState puede ser exited mientras el proceso hijo se ejecuta

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

Preguntas frecuentes

Mi servicio WireGuard aparece como Inactivo en Level pero el tráfico se enruta 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 servicios detecta inactive y dispara 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á saludable? Ejecuta systemctl show -p SubState --value <unit_name> en un dispositivo donde el servicio funciona correctamente. Lo que devuelva es tu referencia saludable. Escribe el script en función de 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 proporciona una cobertura más amplia — puedes detectar servicios que salieron de forma inesperada (SubState: failed) por separado de los servicios que simplemente están detenidos (ActiveState: inactive).
¿Funciona esto en distribuciones 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 Linux con mantenimiento activo incluyen systemd.

Monitorización de archivos de unidad systemd en Linux