Algunos servicios de Linux están diseñados para salir después de la inicialización — y eso confunde a los monitores de servicio. Si está monitoreando uno con un monitor de servicio en Level, obtendrá alertas falsas. La solución es un monitor de script que lee SubState en lugar de ActiveState.
Por qué los monitores de servicio disparan alertas falsas
systemd rastrea cada unidad en dos campos de estado: ActiveState y SubState. Los monitores de servicio verifican ActiveState — valores como active, inactive o failed.
El problema: ciertos servicios salen después de hacer su trabajo y nunca entran en un estado active persistente. El wg-quick de WireGuard es el ejemplo más común. Configura la interfaz VPN y luego sale. systemd registra ActiveState como inactive (exited). Un monitor de servicio ve inactive y dispara una alerta — incluso aunque la VPN funciona correctamente, la interfaz está activa y el tráfico se enruta.
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 realmente salió mal. Verificar SubState directamente es lo que le permite notar la diferencia.
Verificar SubState con un script
Use systemctl show para leer el SubState de cualquier unidad:
systemctl show -p SubState --value <unit_name>
Esto devuelve una única cadena — running, exited, dead, failed, etc. — que puede evaluar en un monitor de script.
🖥️ NOTA DE PLATAFORMA:
Linux: Compatible con cualquier distribución que utilice systemd.
Windows / macOS: No aplicable.
systemctles solo para Linux.
Ejemplo: Monitoreo de una interfaz WireGuard
El script a continuación verifica si wg-quick@wg0 está en el SubState exited esperado. Cambie el nombre de la unidad si el suyo 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 activarse cuando la salida Contiene la cadena de fallo « ALERT ».
Configuración del monitor:
Campo | Valor |
Tipo | Ejecutar script |
SO | Linux |
Script | Linux - WireGuard SubState Check |
Salida del script | Contiene |
Valor |
|
Frecuencia de ejecución | 5 minutos |
Recuento de activadores | 2 |
💡 CONSEJO: Establezca el recuento de activadores en 2 o superior para evitar alertas de estados transitorios durante reinicios o recargas del servicio.
Otros tipos de unidad que salen por diseño
wg-quick es el caso más común, pero cualquiera de estos puede activar el mismo patrón de falsa alerta:
Servicios Oneshot — ejecutan una tarea y salen;
SubStateseráexitedcuando esté saludableUnidades de temporizador — se ejecutan según un calendario; verifique
ActiveStatepara la unidad de temporizador en sí, no para el servicio que iniciaServicios Type=forking — el proceso padre sale después de generar un hijo; SubState puede ser
exitedmientras se ejecuta el hijo
Para todos estos, un monitor de script que verifique SubState contra su valor conocido-bueno es el enfoque correcto.
Preguntas frecuentes
Mi servicio WireGuard aparece como Inactivo en Level pero el tráfico se enruta correctamente. ¿Qué está pasando?
wg-quicksale después de configurar la interfaz VPN — eso es normal. La interfaz de red permanece activa incluso aunque el proceso de servicio haya salido. Un monitor de servicio veinactivey dispara una alerta. Utilice un monitor de script que verifiqueSubState(que devuelveexited, el valor saludable) en su lugar.¿Cómo sé qué valor SubState esperar cuando un servicio está saludable? Ejecute
systemctl show -p SubState --value <unit_name>en un dispositivo donde el servicio funciona correctamente. Lo que devuelva es su línea de base saludable. Programe contra ese valor.¿Puedo verificar tanto ActiveState como SubState en el mismo monitor? Sí. Escriba el script para leer ambos y fallar si alguno es inesperado. Esto le brinda una cobertura más amplia — puede detectar servicios que salieron inesperadamente (
SubState: failed) por separado de servicios que simplemente se detuvieron (ActiveState: inactive).¿Funciona esto en distribuciones de Linux que no utilizan 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 activamente mantenidas incluyen systemd.