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).

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

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)

5.3 KiB Raw Blame History