● Santé · transitions d’état · Telegram · systemd

Watchdog Jarvis

Activer une supervision locale légère qui exécute jarvis-health toutes les 10 minutes, n’utilise aucun LLM pour décider si Jarvis est sain, et n’envoie une notification Telegram que lorsque l’état change.

Source de vérité

jarvis-health

Fréquence

10 minutes

Alertes

Transitions uniquement

Télécharger jarvis-watchdog Voir le script

Principe : le watchdog ne demande pas à Qwen si la machine fonctionne. Il lance jarvis-health, lit son code retour et la ligne SANTÉ:, puis compare le résultat avec l’état précédent.

Pas de spam : si l’état reste identique, aucun message Telegram n’est envoyé. Une alerte est envoyée lors du passage vers DEGRADE/CRITIQUE/ERREUR et une notification de rétablissement lors du retour à OK.

Lecture seuleModificationValidationOptionnel

Architecture du watchdog

Détection

jarvis-health produit OK, DEGRADE ou CRITIQUE et un code retour exploitable.

Mémoire

~/.local/state/jarvis-watchdog/state conserve uniquement le dernier état connu.

Diagnostic

last-health.txt conserve le dernier rapport nettoyé des codes couleur ANSI.

Notification

Hermes envoie le message vers le home channel Telegram déjà défini au Module 09.

Installation et validation

15.1 · Vérifier les prérequis

Validation

command -v jarvis-health
command -v jarvis-watchdog
command -v hermes
command -v flock

jarvis-health
echo "Code retour : $?"

Pourquoi : Le watchdog dépend directement de jarvis-health, de Hermes pour Telegram et de flock pour empêcher deux exécutions simultanées.

Résultat attendu : Les commandes sont trouvées et jarvis-health retourne normalement 0 sur un cœur Jarvis sain.

15.2 · Voir ou télécharger le script public

Lecture seule

# Depuis le site :
#   Voir       : ../scripts/jarvis-watchdog
#   Télécharger: ../scripts/jarvis-watchdog

ls -lh "$HOME/.local/bin/jarvis-watchdog"

Pourquoi : Le script distribué par le site est la version publique dérivée du Golden Build.

Résultat attendu : Le fichier est déjà présent dans ~/.local/bin si le Module 13 a été validé.

15.3 · Valider le script installé

Validation

bash -n "$HOME/.local/bin/jarvis-watchdog"
chmod 700 "$HOME/.local/bin/jarvis-watchdog"
stat -c '%a %n' "$HOME/.local/bin/jarvis-watchdog"

grep -nE '192\.168\.|/home/[A-Za-z0-9._-]+'   "$HOME/.local/bin/jarvis-watchdog" || true

Pourquoi : La version publique doit rester générique et exécutable sans contenir les anciennes valeurs privées du Golden.

Résultat attendu : Syntaxe Bash valide, mode 700 et aucune ancienne IP ou chemin utilisateur réel.

15.4 · Comprendre les fichiers d’état

Lecture seule

grep -nE 'STATE_DIR|STATE_FILE|LAST_REPORT|LOCK_FILE'   "$HOME/.local/bin/jarvis-watchdog"

Pourquoi : Le watchdog mémorise son état hors de la configuration Hermes, dans le répertoire d’état utilisateur.

Résultat attendu : Les chemins reposent sur ~/.local/state/jarvis-watchdog/.

15.5 · Tester Telegram sans simuler de panne

Validation

jarvis-watchdog --test-alert

Pourquoi : L’option --test-alert envoie uniquement un message de test et ne modifie pas l’état du watchdog.

Résultat attendu : Telegram reçoit un message commençant par JARVIS WATCHDOG indiquant qu’il s’agit d’un test.

15.6 · Exécuter le watchdog une première fois

Validation

jarvis-watchdog
echo "Code retour : $?"

Pourquoi : Lors d’une première exécution saine, le script enregistre OK sans envoyer de notification inutile.

Résultat attendu : La sortie indique typiquement Jarvis OK — état initial enregistré. ou État inchangé : OK.

15.7 · Contrôler l’état enregistré

Validation

STATE_DIR="$HOME/.local/state/jarvis-watchdog"
ls -la "$STATE_DIR"
printf 'État mémorisé : '
cat "$STATE_DIR/state"
stat -c '%a %n' "$STATE_DIR/last-health.txt"
tail -n 30 "$STATE_DIR/last-health.txt"

Pourquoi : Le dernier rapport de santé est conservé pour diagnostic et le dernier état sert à dédupliquer les alertes.

Résultat attendu : Le fichier state contient OK sur une machine saine et last-health.txt est lisible uniquement par l’utilisateur.

15.8 · Vérifier la déduplication

Validation

jarvis-watchdog
jarvis-watchdog

Pourquoi : Deux contrôles successifs sans changement ne doivent pas produire deux alertes Telegram.

Résultat attendu : Les exécutions affichent État inchangé : OK et aucun nouveau message d’alerte n’est envoyé.

15.9 · Créer le service systemd utilisateur

Modification

mkdir -p "$HOME/.config/systemd/user"
cat > "$HOME/.config/systemd/user/jarvis-watchdog.service" <<'EOF'
[Unit]
Description=Jarvis Health Watchdog
After=network-online.target

[Service]
Type=oneshot
ExecStart=%h/.local/bin/jarvis-watchdog
EOF

Pourquoi : Le service exécute une seule passe du watchdog. La périodicité sera gérée séparément par le timer.

Résultat attendu : Le fichier jarvis-watchdog.service existe sous ~/.config/systemd/user/.

15.10 · Créer le timer toutes les 10 minutes

Modification

cat > "$HOME/.config/systemd/user/jarvis-watchdog.timer" <<'EOF'
[Unit]
Description=Surveillance régulière de Jarvis

[Timer]
OnBootSec=2min
OnUnitActiveSec=10min
AccuracySec=1min

[Install]
WantedBy=timers.target
EOF

Pourquoi : Ces valeurs correspondent au timer Golden : premier contrôle peu après le démarrage puis toutes les 10 minutes.

Résultat attendu : Le timer est défini sans boucle shell ni cron.

15.11 · Valider les unités systemd

Validation

systemd-analyze --user verify   "$HOME/.config/systemd/user/jarvis-watchdog.service"   "$HOME/.config/systemd/user/jarvis-watchdog.timer"

Pourquoi : Une erreur de syntaxe systemd doit être détectée avant activation.

Résultat attendu : Aucune erreur relative aux deux unités Jarvis.

15.12 · Recharger systemd

Modification

systemctl --user daemon-reload
systemctl --user cat jarvis-watchdog.service
systemctl --user cat jarvis-watchdog.timer

Pourquoi : Le gestionnaire utilisateur doit relire les deux nouveaux fichiers.

Résultat attendu : Les définitions affichées correspondent exactement aux fichiers créés.

15.13 · Vérifier le linger utilisateur

Validation

loginctl show-user "$USER" -p Linger

Pourquoi : Un timer utilisateur doit pouvoir continuer à fonctionner même lorsqu’aucune session interactive n’est ouverte.

Résultat attendu : La sortie affiche Linger=yes. S’il est déjà activé depuis les modules précédents, aucune action supplémentaire.

15.14 · Activer le timer

Modification

systemctl --user enable --now jarvis-watchdog.timer

Pourquoi : Cette commande active le watchdog maintenant et automatiquement lors des prochains démarrages de la session utilisateur/systemd.

Résultat attendu : La commande crée le lien d’activation et le timer devient actif.

15.15 · Contrôler la prochaine exécution

Validation

systemctl --user status jarvis-watchdog.timer --no-pager
systemctl --user list-timers --all | grep jarvis-watchdog

Pourquoi : Il faut vérifier que systemd connaît réellement la prochaine échéance.

Résultat attendu : Le timer apparaît dans la liste avec une prochaine exécution prévue.

15.16 · Tester le service via systemd

Validation

systemctl --user start jarvis-watchdog.service
systemctl --user status jarvis-watchdog.service --no-pager || true
journalctl --user -u jarvis-watchdog.service -n 40 --no-pager

Pourquoi : Le test manuel via systemd valide le même chemin d’exécution que celui utilisé par le timer.

Résultat attendu : Le oneshot termine proprement ; inactive (dead) après succès est normal pour un service Type=oneshot.

15.17 · Vérifier qu’il n’y a qu’une instance

Validation

pgrep -af jarvis-watchdog || true
ls -l "$HOME/.local/state/jarvis-watchdog/lock"

Pourquoi : Le script utilise flock -n : si une exécution est déjà en cours, une seconde quitte immédiatement sans conflit.

Résultat attendu : Pas de processus watchdog bloqué ; le fichier de lock peut exister sans indiquer une panne.

15.18 · Tester un rétablissement contrôlé

Optionnel

STATE="$HOME/.local/state/jarvis-watchdog/state"
cp -a "$STATE" "${STATE}.before-test"
printf 'DEGRADE
' > "$STATE"
chmod 600 "$STATE"

# À lancer uniquement si jarvis-health retourne actuellement 0 / SANTÉ: OK
jarvis-watchdog

cat "$STATE"
rm -f "${STATE}.before-test"

Pourquoi : Ce test ne met aucun service en panne : il simule uniquement un ancien état DEGRADE. Si la santé actuelle est OK, le watchdog doit envoyer un message de rétablissement.

Résultat attendu : Telegram reçoit JARVIS RÉTABLI et le fichier state revient à OK.

15.19 · Consulter les derniers rapports

Lecture seule

STATE_DIR="$HOME/.local/state/jarvis-watchdog"
cat "$STATE_DIR/state"
tail -n 60 "$STATE_DIR/last-health.txt"
journalctl --user -u jarvis-watchdog.service --since today --no-pager | tail -80

Pourquoi : Ces trois sources suffisent généralement à comprendre la dernière décision du watchdog sans relancer de LLM.

Résultat attendu : L’état, le dernier rapport jarvis-health et l’historique systemd sont cohérents.

15.20 · Contrôle final du watchdog

Validation

systemctl --user is-enabled jarvis-watchdog.timer
systemctl --user is-active jarvis-watchdog.timer
systemctl --user list-timers --all | grep jarvis-watchdog
jarvis-watchdog --test-alert

Pourquoi : Ce contrôle regroupe activation, exécution planifiée et canal d’alerte.

Résultat attendu : Le timer est enabled et active, une échéance est visible et le test Telegram est reçu.

Comportement attendu

UNKNOWN → OK

Enregistre OK silencieusement. Pas d’alerte au premier démarrage sain.

OK → OK

Aucun message. Le watchdog indique seulement que l’état est inchangé.

OK → anomalie

Une alerte est envoyée avec état, hostname, date, code retour et extrait utile de jarvis-health.

Anomalie → OK

Une notification JARVIS RÉTABLI est envoyée puis l’état repasse à OK.

Validation du Module 15

Ne passez à la validation finale que lorsque la surveillance est réellement autonome.

jarvis-watchdog passe bash -n.

jarvis-health fonctionne.

--test-alert est reçu sur Telegram.

L’état initial sain est enregistré sans alerte.

Deux états identiques ne génèrent pas de doublon.

last-health.txt est créé en mode privé.

Le service systemd est valide.

Le timer systemd est valide.

Linger=yes.

Le timer est enabled + active.

La prochaine exécution est visible.

Le journal systemd ne montre pas d’échec actif.

STOP — Module 15 validé

Jarvis dispose maintenant d’une supervision locale autonome : diagnostic sans LLM, déduplication des alertes, notification Telegram sur changement d’état et contrôle toutes les 10 minutes. Il ne reste plus que la validation finale du cœur.

← Module précédent Module 16 — Validation finale →