Introduction
Algunos servicios de Linux están diseñados para salir después de la inicialización — y eso dispara monitores de servicio. Si está observando uno con un monitor de servicio en Level, obtendrá alertas falsas. La solución es un monitor de script que leeSubState instead of ActiveState.
Por qué los monitores de servicio disparan alertas falsas
systemd rastrea cada unidad en dos campos de estado:ActiveState and SubState. Los monitores de servicio verificanActiveState — values like active, inactive, or failed.
The problem:ciertos servicios se cierran después de hacer su trabajo y nunca entran en un estado persistenteactiveElwg-quickes el ejemplo más común. Configura la interfaz VPN y luego se cierra. systemd registraActiveState as inactive (exited). Un monitor de servicio veinactivey dispara una alerta — aunque la VPN funciona correctamente, la interfaz está activa y el tráfico se enruta.
SubStatecuenta una historia más precisa. Para servicios comowg-quick, un SubState saludable esexited— esperado y normal. Un SubState defailedsignificaría que algo realmente salió mal. VerificaciónSubStatedirectamente es lo que le permite notar la diferencia.
Verificar SubState con un script
Use systemctl showpara leer el SubState de cualquier unidad:
systemctl show -p SubState --value <unit_name>
Esto devuelve una sola cadena —running, exited, dead, failed, etc. — que puede evaluar en un monitor de script.
🖥️ PLATFORM NOTE:
Linux:Compatible con cualquier distribución que use systemd.
Windows / macOS: Not applicable.
systemctlis Linux-only.
Ejemplo: Supervisión de una interfaz WireGuard
El siguiente script verifica siwg-quick@wg0está en elexitedSubState esperado. Cambie el nombre de la unidad real 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). Configure el monitor de script para que se dispare cuando la salidaContainsla cadena de error "ALERT".
Configuración del monitor:
Field | Value |
Tipo | Run script |
OS | Linux |
Script | Linux - Verificación de SubState de WireGuard |
Script output | Contains |
Value |
|
Run frequency | 5 minutes |
Trigger count | 2 |
💡 TIP: Set Trigger counta 2 o superior para evitar alertas de estados transitorios durante reinicios o reinicios de servicio.
Otros tipos de unidad que se cierran por diseño
wg-quickes el caso más común, pero cualquiera de estos puede desencadenar el mismo patrón de falsa alerta:
Servicios únicos— ejecutan una tarea y se cierran;
SubStatewill beexitedwhen healthyTimer units— se ejecuta según un horario; verificar
ActiveStatepara la unidad de temporizador en sí, no el servicio que lanzaServicios Type=forking— el proceso padre se cierra después de generar un hijo; SubState puede ser
exitedmientras se ejecuta el hijo
Para todos estos, un monitor de script que verificaSubStatecontra su valor conocido-bueno es el enfoque correcto.
FAQ
Mi servicio WireGuard se muestra como Down en Level pero el tráfico se enruta bien. ¿Qué está pasando?
wg-quickse cierra después de configurar la interfaz VPN — eso es normal. La interfaz de red permanece activa aunque el proceso de servicio se cerró. Un monitor de servicio veinactivey dispara una alerta. Use un monitor de script que verifiqueSubState(which returnsexited, el valor saludable) en su lugar.¿Cómo sé qué valor de SubState esperar cuando un servicio es saludable? Run
systemctl show -p SubState --value <unit_name>en un dispositivo donde el servicio funciona correctamente. Lo que sea que devuelva es su línea de base saludable. Script contra ese valor.¿Puedo verificar ActiveState y SubState en el mismo monitor?Sí. Escriba el script para leer ambos y fallar si alguno es inesperado. Esto le da una cobertura más amplia — puede detectar servicios que salieron inesperadamente (
SubState: failed) separado de servicios que simplemente se detuvieron (ActiveState: inactive).¿Funciona esto en distribuciones de Linux que no usan systemd? No.
systemctlrequiere systemd. En distribuciones que usan SysVinit o Upstart, necesitaría herramientas diferentes (por ejemplo,service <name> status). La mayoría de las distribuciones de Linux mantenidas activamente se envían con systemd.