runbook: watchdog tailscale-bridge faux timeout restart + piege compose up -d cible

2026-09-16 02:39:07 +01:00
parent 4eeeef3714
commit 0d60299b13
2 changed files with 25 additions and 0 deletions
@@ -292,3 +292,4 @@
 - [common/correctif-hermes-nabil-deepseek-residuel-ticket048-20260912.md](common/correctif-hermes-nabil-deepseek-residuel-ticket048-20260912.md) -- Correctif suite audit Claude du ticket 047 : recensement de Gemini annonce exhaustif mais bloc delegation de hermes-nabil (VPS) reste sur deepseek/deepseek-v4-flash via openrouter direct (hors VK Bifrost, donc invisible a la verification centree Bifrost). Corrige par Claude (backup, bascule vers mimo-v2.5 via bifrost-proxy, YAML valide, conteneur redemarre proprement, routage teste reel -- 429 GoUsageLimitError du quota OpenCode Go global, etat pre-existant sans lien avec le correctif). Tirith identifie au passage : sous-systeme de securite interne a hermes-nabil (scan statique), pas un consommateur de modele. Ticket 047 cloture avec reserves, ticket 048 cloture definitif (12/09/2026)
 - [common/deploiement-antigravity-cli-context-mode-ticket049-20260913.md](common/deploiement-antigravity-cli-context-mode-ticket049-20260913.md) -- Déploiement Antigravity CLI VPS (ticket infra-2026-09-049) : autorisation clé SSH opencode-ops sur NAS (gemini-ops:22222) validée agy-web/opencode, ajout et activation MCP baserow-nyora (fix 401 via insertion core_mcpendpoint workspace 186, test réel agy 10 tables OK), intégration pérenne context-mode sur agy-web (Dockerfile node:22-slim, npm install -g, plugin agy, doctor PASS) (13/09/2026)
 - [common/backup-usb-cache-io-errors-fix-20260914.md](common/backup-usb-cache-io-errors-fix-20260914.md) -- Échecs backup-usb.sh deux semaines de suite (07/09 puis 14/09/2026, rc=23) : diagnostic — rsync --link-dest relit le backup precedent (31/08) pour le hardlink, et des fichiers de .cache/uv (paquets Python hermes-tt) y remontaient des erreurs Input/output error ; la rotation ne purge qu'en succes donc les backups en echec s'accumulaient sans etre nettoyes. Script corrige (backup .bak-20260914 conserve) : exclusion des caches ephemeres (.cache/uv, .cache/pip, .cache/ms-playwright, __pycache__, node_modules/.cache) et fix du bug exit 0 implicite qui masquait l'echec au Task Scheduler DSM (status affichait Success malgre BACKUP EN ECHEC). Backup relance manuellement et valide : rc=0/rc=0, zero erreur I/O, 96G, _BACKUP_OK present (14/09/2026)
+- [common/watchdog-tailscale-bridge-faux-timeout-restart-20260916.md](common/watchdog-tailscale-bridge-faux-timeout-restart-20260916.md) -- tailscale-bridge-watchdog (cree 05/09, jamais documente/versionne avant ce jour) : fausse alerte Telegram "Echec apres redemarrage automatique / SOCKS5 Name does not resolve" causee par un timeout de 20s trop court sur le docker restart du pont (tailscaled+socat), sous charge NAS elevee (swap 5.0Gi/13Gi, load 8.08) ; pont en fait deja retabli par le 2e cycle de remediation automatique avant intervention. Fix : timeout 20s->45s + attente post-restart 15s->20s, rebuild/redeploy verifie. Piege decouvert au passage : docker compose up -d cible sur un seul service a recree le bridge (depends_on) sans le redemarrer (etat Created, corrige manuellement) -- toujours faire un up -d complet du compose en presence de depends_on. Repo tailscale-nyora-bridge initialise et pousse sur Gitea pour la premiere fois (16/09/2026)
@@ -0,0 +1,24 @@
+# Watchdog tailscale-nyora-bridge : fausse alerte "echec apres redemarrage" (16/09/2026)
+
+## Contexte
+tailscale-bridge-watchdog (cree le 05/09/2026, ticket infra-2026-09-019, jamais documente ni versionne depuis) surveille en continu SOCKS5/HTTP/SSH du pont tailscale-nyora-bridge. Sur 3 echecs consecutifs, il declenche une remediation automatique (docker restart bridge + stub bifrost), puis alerte Telegram si la remediation echoue.
+
+## Incident
+Nuit du 15 au 16/09/2026 : SSH_RELAY timeouts intermittents (01h06, puis 01h16-01h18) -> seuil critique atteint -> 1er `docker restart tailscale-nyora-bridge` execute, mais NAS sous forte charge (load average ~8, swap 5.0Gi/13Gi utilise) -> le restart a depasse le timeout de 20s code en dur dans le script, tue avant confirmation -> health-check suivant echoue avec `SOCKS5: [Errno -2] Name does not resolve` (DNS Docker indisponible pendant la fenetre de redemarrage) -> alerte Telegram envoyee ("Echec apres redemarrage automatique"). Un 2e cycle de remediation automatique, 2 minutes plus tard, a reussi (restart en 13s cette fois) et le pont est reste sain en continu depuis. Aucune intervention manuelle n'etait donc necessaire sur le fond -- seulement une fausse alerte.
+
+## Cause racine
+Le timeout de la commande `docker restart tailscale-nyora-bridge` dans bridge_watchdog.py (fonction `sh()`, defaut 20s) est trop serre pour ce conteneur (tailscaled + socat co-processes) des que le NAS est sous pression memoire/IO -- deja signale le 30/08 (swap 4.1Gi/13Gi), en aggravation le 16/09 (5.0Gi/13Gi, load 8.08).
+
+## Fix applique
+- `watchdog/bridge_watchdog.py` : `sh("docker restart tailscale-nyora-bridge")` -> `timeout=45` explicite (au lieu du defaut 20s)
+- Attente post-remediation avant re-test : `time.sleep(15)` -> `time.sleep(20)`
+- Image rebuild + redeploiement, verifie healthy immediatement apres (check #1 OK)
+
+## Piege operationnel decouvert pendant le fix
+`docker compose up -d tailscale-bridge-watchdog` (cible un seul service du compose) a recree tailscale-nyora-bridge (dependance depends_on) SANS le redemarrer, le laissant en etat `Created` (donc hors service, pont NAS<->VPS coupe brievement) pendant que le watchdog echouait a demarrer (conflit de nom sur l'ancien conteneur). Correction : `docker start` explicite du bridge, `docker rm -f` de l'ancien watchdog, puis `docker compose up -d` SANS filtre de service pour recreer proprement les deux dans l'ordre. A eviter a l'avenir : toujours faire un `up -d` complet du compose (pas cible sur un service ayant des dependances) quand un depends_on est en jeu.
+
+## A signaler
+Le TS_AUTHKEY est en clair dans docker-compose.yml, desormais commite dans bolbol/tailscale-nyora-bridge (repo prive, pas de rotation faite -- a evaluer si ca merite un passage en .env/.secrets-staging comme les autres credentials).
+
+## Non traite (hors perimetre de ce fix)
+Pression memoire/swap du NAS en aggravation (5.0Gi/13Gi de swap, load average 8.08 au moment de l'incident) -- cause racine plus large deja notee le 30/08/2026, necessite un audit dedie des conteneurs consommateurs.