Certains services Linux sont conçus pour quitter après l'initialisation — et cela confond les moniteurs de service. Si vous en surveillez un avec un moniteur de service dans Level, vous obtiendrez de fausses alertes. La solution est un moniteur de script qui lit SubState au lieu de ActiveState.
Pourquoi les moniteurs de service déclenchent des fausses alertes
systemd suit chaque unité sur deux champs de statut : ActiveState et SubState. Les moniteurs de service vérifient ActiveState — des valeurs comme active, inactive, ou failed.
Le problème : certains services quittent après avoir fait leur travail et n'entrent jamais dans un état active persistant. Le wg-quick de WireGuard en est l'exemple le plus courant. Il configure l'interface VPN, puis quitte. systemd enregistre ActiveState comme inactive (exited). Un moniteur de service voit inactive et déclenche une alerte — même si le VPN fonctionne correctement, l'interface est active et le trafic est routé.
SubState raconte une histoire plus précise. Pour les services comme wg-quick, un SubState sain est exited — attendu et normal. Un SubState de failed signifierait que quelque chose s'est réellement mal passé. Vérifier SubState directement vous permet de faire la différence.
Vérifier SubState avec un script
Utilisez systemctl show pour lire le SubState de toute unité :
systemctl show -p SubState --value <unit_name>
Cela retourne une chaîne unique — running, exited, dead, failed, etc. — que vous pouvez évaluer dans un moniteur de script.
🖥️ NOTE DE PLATEFORME :
Linux : Supporté sur toute distribution utilisant systemd.
Windows / macOS : Non applicable.
systemctlest spécifique à Linux.
Exemple : surveillance d'une interface WireGuard
Le script ci-dessous vérifie si wg-quick@wg0 est dans le SubState exited attendu. Remplacez le nom de l'unité si le vôtre est différent.
#!/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
Le script affiche une chaîne de statut lisible et quitte avec le code 0 (sain) ou 1 (état inattendu). Configurez le moniteur de script pour déclencher lorsque la sortie Contient la chaîne d'échec « ALERT ».
Configuration du moniteur :
Champ | Valeur |
Type | Exécuter un script |
SE | Linux |
Script | Linux - WireGuard SubState Check |
Sortie du script | Contient |
Valeur |
|
Fréquence d'exécution | 5 minutes |
Nombre de déclenchements | 2 |
💡 CONSEIL : Définissez le nombre de déclenchements à 2 ou plus pour éviter les alertes des états transitoires lors des redémarrages ou reboots du service.
Autres types d'unités qui quittent par conception
wg-quick est le cas le plus courant, mais l'un de ces cas peut déclencher le même modèle de fausse alerte :
Services Oneshot — exécutent une tâche et quittent ;
SubStateseraexitedquand sainUnités de minuteur — s'exécutent selon un calendrier ; vérifiez
ActiveStatepour l'unité de minuteur elle-même, pas le service qu'elle lanceServices Type=forking — le processus parent quitte après avoir créé un enfant ; SubState peut être
exitedpendant que l'enfant s'exécute
Pour tous ceux-ci, un moniteur de script vérifiant SubState contre votre valeur connue-bonne est la bonne approche.
FAQ
Mon service WireGuard apparaît comme Arrêté dans Level mais le trafic est routé correctement. Que se passe-t-il ?
wg-quickquitte après avoir configuré l'interface VPN — c'est normal. L'interface réseau reste active même si le processus de service a quitté. Un moniteur de service voitinactiveet déclenche une alerte. Utilisez plutôt un moniteur de script qui vérifieSubState(qui retourneexited, la valeur saine).Comment sais-je quelle valeur SubState attendre quand un service est sain ? Exécutez
systemctl show -p SubState --value <unit_name>sur un appareil où le service fonctionne correctement. Quoi qu'il retourne est votre ligne de base saine. Écrivez un script contre cette valeur.Puis-je vérifier à la fois ActiveState et SubState dans le même moniteur ? Oui. Écrivez le script pour lire les deux et échouer si l'un ou l'autre est inattendu. Cela vous donne une couverture plus large — vous pouvez détecter les services qui ont quitté inopinément (
SubState: failed) séparément des services qui sont simplement arrêtés (ActiveState: inactive).Cela fonctionne-t-il sur les distributions Linux qui n'utilisent pas systemd ? Non.
systemctlnécessite systemd. Sur les distributions utilisant SysVinit ou Upstart, vous auriez besoin d'outils différents (par exemple,service <name> status). La plupart des distributions Linux activement maintenues incluent systemd.