infra: watchdog telegram gateway en container autonome (27/07/2026)

This commit is contained in:
2026-07-27 22:55:57 +00:00
parent a76e387596
commit 460850714b
3 changed files with 70 additions and 0 deletions
+2
View File
@@ -164,3 +164,5 @@
- [common/veille-chunking-nyora-root-cause.md](common/veille-chunking-nyora-root-cause.md) -- Root cause des 24 tool_calls casses hermes-nyora : prompt du job veille ordonnait un heredoc unique pour 20 items sans limite, pas un probleme mimo-v2.5 ; fix construction chunkee (27/07/2026)
- [common/watchdog-telegram-gateway-container-autonome.md](common/watchdog-telegram-gateway-container-autonome.md) -- Watchdog Telegram gateway Hermes en container autonome (docker:cli + socket monte), contourne l'absence d'acces DSM Task Scheduler/crontab, redemarre automatiquement + escalade si echec persistant (27/07/2026)
+4
View File
@@ -185,3 +185,7 @@ Passage de manual/auto (valeur invalide sur tt) a `smart` sur hermes-perso, herm
Les 24 incidents "Unrepairable tool_call arguments" venaient du prompt du cron veille-ia-nexum-4ee61494 qui ordonnait d'ecrire jusqu'a 20 analyses (champs sans limite de longueur) en UN SEUL heredoc -- exact anti-pattern du skill generation-contenu-volumineux, qui perd face a une instruction de prompt precise et contraire. Ce n'etait pas un probleme de fiabilite du modele. Fix : prompt reecrit pour une construction chunkee (1 fichier /tmp/veille_item_NN.json par opportunite, assemblage par script Python, jamais un nouvel appel LLM pour la fusion). Reflexe a generaliser : avant de blamer un modele sur des echecs de tool_call recurrents sur une tache precise, verifier D'ABORD si le prompt de cette tache contredit la regle de generation chunkee. Detail : common/veille-chunking-nyora-root-cause.md.
## FIX -- watchdog telegram gateway autonome, sans acces DSM Task Scheduler (2026-07-27)
Incident hermes-perso (gateway Telegram bloque 2h17 en silence). Best0f n'a pas de sudo general (scope docker/rsync/journalctl), pas d'acces DSM Task Scheduler, pas de crontab utilisateur disponible -- ne jamais chercher a contourner ca en devinant un mot de passe ou en modifiant sudoers sans geste explicite de Nabil lui-meme. Solution retenue : container autonome `hermes-watchdog-telegram` (image docker:cli + python3, socket Docker monte, --restart unless-stopped) qui verifie toutes les 10 min les 3 instances NAS pour le motif exact de l'incident, redemarre automatiquement si detecte, et n'alerte (webhook veille-infra) que si un redemarrage automatique n'a pas suffi. Pattern reutilisable : toute tache planifiee cote NAS realisable via des commandes docker peut passer par un petit container autonome plutot que par le Planificateur DSM. Detail : common/watchdog-telegram-gateway-container-autonome.md.
@@ -0,0 +1,64 @@
# Watchdog Telegram gateway Hermes -- container autonome, sans acces DSM Task Scheduler
**Instance auteur** : Claude
**Date** : 2026-07-27
**Tags** : [infra, telegram, watchdog, hermes, transverse]
**Statut** : valide
---
## Probleme
Incident hermes-perso du 27/07 (voir note memoire du meme jour) : gateway Telegram bloque 2h17 en silence apres une erreur "Bad Gateway" transitoire cote Telegram -- le mecanisme interne de reconnexion de Hermes a lui-meme echoue sans le signaler, et le healthcheck Docker ne detecte pas ce type de panne (il verifie juste que le process tourne). Besoin d'une detection + correction automatique, sans intervention manuelle.
## Contexte et contraintes
Le compte Best0f (acces SSH utilise par Claude sur ce NAS) a des droits sudo scopes a docker/rsync/journalctl uniquement (pas de sudo general, pas de mot de passe disponible). Consequence directe : impossible de creer une tache dans le Planificateur de taches DSM (Synology, gere par `synoschedtask`, necessite les droits admin DSM) ni d'utiliser un crontab utilisateur classique (le binaire `crontab` n'est meme pas installe pour ce compte). Cette limitation est volontaire et ne doit pas etre contournee en cherchant un mot de passe ou en modifiant sudoers -- seul Nabil peut elargir ces droits, et ca reste un geste manuel equivalent a ce qu'on veut eviter.
## Ce qui NE fonctionne PAS
| Tentative | Erreur / limite | Raison |
|-----------|------------------|--------|
| `sudo -l` / sudo general | "a password is required" | Sudoers scope a docker/rsync/journalctl, pas de mot de passe connu de Claude |
| Creer une tache DSM Task Scheduler via SSH | Aucun acces -- necessite les droits admin DSM (interface web ou API authentifiee) | `synoschedtask` est une couche proprietaire, pas un simple fichier editable |
| `crontab -e` (utilisateur Best0f, sans sudo) | `crontab: command not found` | Binaire absent de l'environnement de ce compte |
| Editer `/etc/crontab` directement | Necessiterait root ; de toute facon ecrase par DSM au prochain enregistrement d'une tache via l'interface | Fichier entierement gere par synoschedtask, pas destine a l'edition manuelle |
## Solution validee
Le compte Best0f a en revanche un acces docker direct et fonctionnel (deja utilise tout au long de la session : `docker restart`, `docker logs`, etc., sans sudo). Solution : faire tourner le watchdog **dans son propre container**, avec le socket Docker monte, plutot que de dependre d'un ordonnanceur externe (DSM ou cron hote).
```bash
docker run -d --name hermes-watchdog-telegram \
--restart unless-stopped \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /volume1/docker/hermes-platform/watchdog-telegram:/watchdog-data \
--entrypoint sh \
docker:cli \
-c 'apk add --no-cache python3 >/dev/null 2>&1; while true; do python3 /watchdog-data/watchdog_telegram_gateway_container.py; sleep 600; done'
```
Image `docker:cli` (Alpine + CLI Docker officiel) choisie pour rester leger tout en gardant le binaire `docker` deja present -- seul `python3` est ajoute via `apk` au demarrage (une seule fois, pas a chaque cycle). `--restart unless-stopped` : le container survit a un reboot du NAS (redemarre automatiquement avec le demon Docker).
Script (`watchdog_telegram_gateway_container.py`) : verifie toutes les 10 min les 3 instances NAS (hermes-agent-perso/tt/nyora) pour le motif exact de l'incident du 27/07 (marqueur d'erreur fatale "Fatal telegram adapter error" / "Restarting gateway" sans marqueur de reconnexion reussie apres, depuis plus de 10 min). Si detecte : `docker restart` du container concerne, silencieux. Si le MEME episode d'erreur persiste apres un redemarrage automatique deja tente (etat trackee dans `state.json`) : alerte envoyee via le webhook veille-infra existant (Email + Telegram) -- escalade uniquement quand un redemarrage automatique n'a pas suffi.
## Verification
```bash
docker ps --filter name=hermes-watchdog-telegram # Up, restart policy unless-stopped
docker exec hermes-watchdog-telegram docker ps # confirme l'acces au socket depuis l'interieur
cat /volume1/docker/hermes-platform/watchdog-telegram/watchdog.log # vide = rien a signaler (normal)
cat /volume1/docker/hermes-platform/watchdog-telegram/state.json # etat de suivi par instance
```
Premier passage teste le 27/07/2026 : acces socket confirme, aucune anomalie detectee (etat sain au moment du test).
## Pieges specifiques
- Ne jamais chercher a obtenir ou deviner un mot de passe sudo, ni modifier sudoers sans une demande explicite et deliberee de Nabil realisee par lui-meme -- la portee actuelle (docker/rsync/journalctl) est un choix de securite assume.
- Pattern reutilisable : tout besoin de tache planifiee cote NAS qui necessiterait normalement le Planificateur DSM peut etre resolu par un petit container autonome avec socket Docker monte, du moment que l'action necessaire est faisable via des commandes docker (pas de sudo general requis).
- Le container watchdog lui-meme n'apparait pas dans l'audit `EXPECTED = 43` de veille_infra.py (compteur de containers) -- a mettre a jour si le compte devient une source d'alerte "conteneur en trop".
## References
- Note memoire 27/07 : incident hermes-perso bloque sur Telegram (diagnostic + fix manuel initial)
- common/smart-approvals-deny-rules-4-instances.md (meme session, meme esprit de garde-fou)