bolbol/nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

protocol-infra: fix nyora-notes-tt disk I/O error post-backup (moteur sqlite mixte)

Browse Source
This commit is contained in:
hermes-tt
2026-08-02 14:51:39 +00:00
committed by Claude
parent 51acc8a303
commit 31b98fcbc9
1 changed files with 3 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
common/PROTOCOL-INFRA.md
+3
View File
@@ -189,3 +189,6 @@ Les 24 incidents "Unrepairable tool_call arguments" venaient du prompt du cron v
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. 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.
## FIX -- nyora-notes-tt : disk I/O error post-backup, moteur SQLite mixte sur WAL live (2026-08-02)
Tous les tools MCP RAG mail cassaient juste apres chaque backup n8n (toutes les 2h) : sqlean.dbapi2.OperationalError: disk I/O error des l'ouverture de connexion. Pas de piste materielle (dmesg propre, volume a 70%). Cause : la route /backup ouvrait une connexion avec le module sqlite3 stdlib, un moteur different de sqlean (utilise partout ailleurs dans l'app sur la meme DB WAL). Le checkpoint automatique au close() de cette connexion stdlib recree le -wal/-shm pendant que les connexions sqlean deja ouvertes tiennent encore les anciens fd -> index WAL desynchronise entre les deux moteurs -> disk I/O error. Absence de PRAGMA busy_timeout aggravait (echec dur au lieu d'attente). Reflexe a generaliser pour tout futur service Hermes/nyora-notes-* sur sqlean+WAL : jamais un deuxieme moteur/binding SQLite (stdlib, autre) sur une DB WAL live partagee avec un process long-vivant, meme pour une simple sauvegarde -- un seul moteur par DB, et PRAGMA busy_timeout systematique a l'ouverture de toute connexion. Detail : hermes-tt/nyora-notes-tt-backup-wal-moteur-mixte.md.