2026 OPENCLAW
GATEWAY_
ACTIF_
RPC_
MORT.

Après passage à OpenClaw v2026.5.2, le mode de panne dominant n'est pas l'arrêt du processus, mais : Gateway reste Active alors que /health, openclaw status et le polling Dashboard expirent simultanément, sessions.list prend souvent 30–70 secondes et la CPU reste bloquée à 95–100 %. Les issues communautaires relient cela à une compaction de transcript qui bloque la boucle d'événements, amplifiée par de gros magasins de sessions (centaines de Mo, milliers de jsonl) et des déploiements multi-agent/Telegram. Cet article fournit matrice de symptômes, tableau de décision, runbook en six étapes, trois portes d'acceptation, étude de cas, notes sectorielles, seuils numériques et FAQ, avec liens vers nos billets sur le gel JSONL multi-canal, la config invalide et doctor --fix et le skillsSnapshot obsolète, afin de valider et rollback sur un nœud de référence Gateway Apple Silicon distant.

1. Points de douleur : « Active mais injoignable » ≠ « canaux silencieux »

(1) Timeout de surface HTTP : le processus Gateway tourne, le port 18789 écoute (lsof -i :18789), mais curl /health et openclaw gateway status --deep --require-rpc dépassent le budget par défaut de 10 s — les ops confondent facilement cela avec le réseau ou le pare-feu. (2) Famine RPC du plan de contrôle : pendant la compaction, sessions.list, cron.list et node.list passent de la sous-seconde à 33–145 s ; chaque appel WebSocket s'empile. (3) Cause racine distincte du gonflement JSONL : les gels Bootstrap viennent souvent de jsonl géants ; la régression 5.2 montre fréquemment des blocages synchrones de compaction de 10–15 s avec un délai de boucle d'événements de l'ordre de dizaines de secondes. (4) Effets secondaires de migration d'état : le saut de 2026.4.24 à 5.2 peut laisser un état qui ralentit même d'anciens binaires jusqu'au nettoyage. (5) Mac distant 7×24 amplifie : les timeouts sur portable invitent aux reboots bricolés ; un nœud de production exige un quadruplet gelé version – taille du magasin de sessions – fenêtre de compaction – échantillon CPU avant toute modification.

2. Matrice de décision : allègement, downgrade ou rollback ?

Signal	Première action	À éviter
Timeout /health + CPU >90 % + sessions.list >30 s	Pause des écritures hors fenêtre de compaction → archiver jsonl → désactiver temporairement Telegram/recherche mémoire	Pas de rm -rf de tout l'arborescence sessions en pic
Seul le Dashboard est lent ; CLI intermittent	Réduire la fréquence de poll ; gateway restart --wait	Ne pas éditer openclaw.json sans sauvegarde
Tous les canaux morts après upgrade 5.2	Épingler sur 2026.4.24 ; diff des répertoires d'état	Pas de « faux upgrade » CLI seul
Une session agent gigantesque	Archiver jsonl/transcript par agent	Ne pas mélanger avec les correctifs skillsSnapshot
Changement production auditable	Exécuter les six étapes d'abord sur le nœud de référence distant	Ne pas clôturer le ticket sans fenêtre de sonde de 30 min

3. Runbook en six étapes

Étape 1 Geler les preuves

Capturer version, uptime PID Gateway, du -sh sur les répertoires de sessions, mots-clés compaction dans les logs. Joindre les 300 dernières lignes de log au ticket.

Étape 2 Échelle de diagnostic officielle

openclaw status → gateway status → doctor → channels status --probe. Si status expire lui-même : confirmer processus/port avec ps/lsof avant toute modification de config.

Étape 3 Allègement en couches du magasin de sessions

Sauvegarde, puis archiver les jsonl au-dessus des seuils par agent. Objectif : sessions.list sous 3 s, pas zéro fichier.

Étape 4 Matrice de downgrade fonctionnel temporaire

Basculer polling Telegram, recherche mémoire, Bonjour, etc. ; journaliser CPU et latence RPC avant/après chaque bascule pour localiser les goulots.

Étape 5 Redémarrage ordonné et sondes RPC

openclaw gateway restart --force --wait, puis trois appels chronométrés gateway status --deep --require-rpc. Sur hôtes launchd : launchctl kick -k et répéter.

Étape 6 Référence distant 7×24 et fenêtre de rollback

Répéter sur Mac de référence ; comparer P95 de sessions.list. Si 5.2 échoue encore au SLO, épingler la production sur 2026.4.24 jusqu'à une release corrigée. Exiger 30 minutes de /health vert et sondes canaux avant clôture.

4. Trois portes d'acceptation

Accessibilité : /health réussit trois fois en moins de 2 s. RPC : sessions.list trois fois en moins de 5 s (10 s avec magasins larges documentés). Canaux : sondes vertes pendant 30 minutes sans récidive de timeout.

5. Étude de cas : Dashboard gris, Telegram répond parfois

Un bot on-call SaaS sur un Mac distant loué a subi une famine du plan de contrôle après l'upgrade : Dashboard mort, openclaw status en timeout, Telegram délivrant encore des réponses sporadiques via connexions longues — presque classé à tort comme panne couche canal. L'archivage de 380 Mo de jsonl historique et la désactivation temporaire de la recherche mémoire ont ramené la CPU sous 40 % et restauré /health. Le nœud de référence est resté sur 2026.4.24 jusqu'à maturité de 5.2 ; le ticket de changement interdit les upgrades en pic du vendredi.

Distinction avec le billet JSONL : jsonl surdimensionné ralentit le bootstrap ; compaction 5.2 fige la boucle en cours. Pour skills obsolètes, lire le runbook skillsSnapshot — les tempêtes de reset pendant les gels grossissent jsonl et aggravent la compaction.

6. Regard sectoriel : le SLO plan de contrôle est la barre 2026

Les agents compactent les transcripts in-process — les ops ont besoin de fenêtres de compaction et de SLO RPC (ex. sessions.list P95 <5 s). Les acheteurs exigent histogrammes de latence health et courbes de magasin de sessions, pas seulement des chaînes de version. Leçon : Active ≠ Healthy. Les clusters Mac distants doivent garder des références dorées sur des pins rollback-friendly.

Les gateways Windows/Linux subissent les mêmes blocages avec d'autres gestionnaires de service. Pour workflows Agent multimédia et mémoire dédiée 24/7, beaucoup d'équipes préfèrent encore un Mac distant Apple Silicon comme environnement doré. Pour répéter régression 5.2, allègement et rollback sur un nœud isolé compatible snapshots, louez un MACGPU Mac distant : passez le runbook six étapes et les sondes 30 minutes sur matériel de référence avant de toucher la production — la latence RPC des deux bouts convainc l'équipe et l'audit.

7. Seuils numériques

(1) Sessions par agent >200 Mo et sessions.list >10 s : archiver avant upgrade. (2) Trois échecs /health au-delà de 2 s : marquer Unhealthy. (3) event loop delay >5000 ms dans les logs compaction : fenêtre de changement ; pas d'installs de skills. (4) Sondes RPC en échec 30 min après upgrade 5.2 : rollback par défaut vers 2026.4.24. (5) Écart de version entre référence distante et production : bloquer les fusions de config.

8. FAQ

Écart vs dépannage générique « pas de réponse » ? Souvent couche auth/canal ; ici le plan de contrôle expire avec CPU saturée. Redémarrage sans allègement ? Soulagement temporaire seulement sur gros magasins. Docker ? Même logique ; attention I/O volume. Rollback obligatoire vers 4.24 ? Selon votre SLO RPC. Rôle MACGPU ? Acceptation de référence et fenêtres de rollback — pas un substitut à votre approbation de changement.