Codes de sortie de la passerelle OpenClaw sur macOS en 2026 : OOM 137, SIGTERM 143, boucles launchd et diagnostics Console.app

Les opérateurs connaissent les passerelles OpenClaw par leurs journaux heureux, mais la production enseigne le vocabulaire des codes de sortie. En 2026, macOS launchd enveloppe encore les runtimes Node de la même façon, que vous auto-hébergiez sur un Mac mini studio ou que vous en louiez un dans le cloud : 137 murmure souvent une pression mémoire, 143 annonce fréquemment un SIGTERM poli pendant les rechargements, et les réapparitions rapides pointent vers des erreurs de plist plutôt que vers la qualité du modèle. Ce guide relie codes et signaux, montre comment filtrer les journaux unifiés sans se noyer, rattache les symptômes au guide doctor pour la passerelle, et explique quand capturer un échantillon Activity Monitor avant d’augmenter la concurrence.

À combiner avec les motifs de récupération LaunchAgent pour des redémarrages propres et la mémoire et l’élagage de contexte lorsque conversations et sorties d’outils grossissent sans limite.

Aide-mémoire des codes de sortie

Code	Sens typique	Premiers contrôles
0	Arrêt propre	Confirmer arrêt volontaire contre watchdog
1	Erreur Node générique	Lire le chemin stderr ; relancer au premier plan
137	OOM / SIGKILL	Pression mémoire, taille des sorties d’outils, contexte modèle
143	SIGTERM	Rechargement launchd, kill manuel, script de déploiement

macOS expose aussi des événements Jetsam pour les apps GUI ; les démons laissent plutôt des traces dans le journal unifié avec des motifs textuels — mémorisez l’orthographe exacte du bundle id pour garder des prédicats étroits.

Les wrappers systemd sur Linux traduisent différemment les signaux ; imposez une nomenclature interne « code + signal + motif launchd » pour éviter les tickets dupliqués entre équipes plateforme et appli.

ThrottleInterval launchd et boucles de crash

Lorsqu’un job sort non nul, launchd applique un backoff. Si votre plist définit KeepAlive avec une réapparition agressive et que le processus meurt en moins d’une seconde, les opérateurs voient un mur d’horodatages identiques qui masque la première vraie ligne d’erreur. Montez temporairement ThrottleInterval à 10 secondes pendant le debug, corrigez la cause racine, puis rétablissez une valeur plus serrée pour la réactivité prod.

Documentez si RunAtLoad est vrai : des faux positifs surviennent quand des ingénieurs déchargent manuellement des agents en journée mais que l’automatisation les recharge quelques minutes plus tard, masquant le véritable déclencheur.

Si vous combinez un daemon système et un LaunchAgent utilisateur, vérifiez que vous inspectez le bon domaine (gui/$UID contre system) — les codes identiques peuvent provenir de deux plists concurrentes.

Prédicats log show lisibles

log show --last 30m --predicate \
  'subsystem == "com.apple.xpc.launchd" AND eventMessage CONTAINS[c] "openclaw"'

Resserrez avec process == "launchd" plus votre chaîne de label. Exportez du JSON pour les post-mortems afin que les auditeurs puissent grep sans shell SSH.

Pour les incidents nocturnes, archivez aussi log show --start ... --end ... borné sur la fenêtre de déploiement ; les flux « last » peuvent tronquer la première respiration si le job redémarre trop vite.

Flux Console.app

1. Créez un favori « Sorties passerelle » combinant sous-système et contient message.
2. Démarrez le flux avant reproduction ; mettez en pause juste après le crash pour limiter la perte de tampon.
3. N’attachez un sysdiagnose que si vous suspectez des fichiers ou extensions — gardez la preuve légère sinon.

Les filtres partagés par équipe réduisent le temps avant la première lecture utile ; versionnez-les dans le dépôt ops comme du code.

Pression mémoire et fan-out d’outils

La sortie 137 corrèle souvent avec des appels d’outils parallèles qui tamponnent chacun plusieurs mégaoctets de stdout. Plafonnez la concurrence à trois lorsque l’hôte dispose de 8 Go de mémoire unifiée, ou réduisez les fenêtres de contexte modèle sous le pic observé dans Activity Monitor. Si la compression mémoire s’active, la latence grimpe avant le kill brutal — ce signal annonce la panne.

Alignez les politiques d’élagage avec l’article mémoire : faites tourner les transcripts, bornez la profondeur JSON et refusez les pièces jointes surdimensionnées à la passerelle plutôt que de laisser Node les parser entièrement.

Quand échantillonner le processus Node

Si le CPU reste à 100 % plus de deux minutes sans journaux de progression, capturez un échantillon depuis Activity Monitor et archivez-le à côté de la version du plist. Les échantillons révèlent des boucles serrées dans du middleware personnalisé qui n’apparaissent pas comme traces stderr classiques.

Hygiène plist : KeepAlive, RunAtLoad

Utilisez SuccessfulExit sous KeepAlive seulement lorsqu’une sortie zéro signifie réellement « malsain ». Des booléens mal configurés poussent launchd à redémarrer des arrêts sains, brûlant des crédits CPU sur des hôtes Mac cloud. Validez avec launchctl print gui/$UID/votre.label et capturez l’écran pour la gestion du changement.

Pourquoi la CI Linux ne reproduit pas

Les conteneurs CI n’ont pas le même compresseur mémoire unifié, le même cycle de vie launchd ni les invites Trousseau. Traitez les tests Linux comme du lint : exécutez quand même une boucle fumée macOS avant de promouvoir des builds passerelle. Un Mac mini loué comble l’écart pour environ 16,9 USD par jour au lieu d’expédier des portables.

Les limites de descripteurs de fichiers par défaut diffèrent aussi ; un upload volumineux peut réussir sur Linux et échouer sur macOS lorsque des sockets restent ouverts.

Modèle de post-mortem

• Chronologie de la dernière requête saine jusqu’à la première ligne de crash.
• Code de sortie, signal et motif launchd textuel.
• Pic mémoire et nombre d’outils concurrents.
• Empreinte sortie doctor et diff de config depuis le dernier déploiement.
• Suivi : changement code, plist ou capacité.

Rotation stderr et sorties disque plein

Certaines passerelles sortent avec le code 1 lorsque StandardErrorPath ne peut plus appendre parce que le volume est plein. Le journal unifié macOS tourne toujours, mais pas les fichiers plats. Surveillez l’espace libre sur /private/var et votre répertoire de logs ; gardez au moins 5 Go sur les Mac mini partagés où plusieurs agents écrivent des dumps verbeux.

Préférez newsyslog ou des wrappers façon logrotate documentés dans votre runbook à des fichiers uniques sans borne — analyser une queue stderr de 12 Go sous stress engendre des incidents secondaires.

Signaux pendant les scripts de déploiement

Les scripts bleu/vert envoient souvent SIGTERM, attendent 15 s, puis escaladent vers SIGKILL. Si votre processus Node intercepte SIGTERM pour drainer des connexions HTTP mais que les appels d’outils dépassent la fenêtre de grâce, launchd enregistre 137 même si l’opérateur croyait un arrêt propre. Allongez la grâce ou réduisez le fan-out avant de permuter les binaires.

Exposez un endpoint /readyz qui passe à faux avant SIGTERM pour que les répartiteurs cessent immédiatement le trafic — ce motif réduit les kills forcés plus que le simple réglage de drapeaux Node.

Métriques enregistreur de vol

Exportez process_start_timestamp_seconds, process_exit_code et rss_bytes_max vers Prometheus même sur les petites installations. Quand les codes de sortie explosent, ces trois séries indiquent si vous combattez la mémoire, le churn de déploiement ou une config fragile sans ouvrir un portable.

Ajoutez un compteur de redémarrages launchd corrélé au label ; un spike simultané avec la latence HTTP révèle souvent un problème de plist plutôt qu’un modèle lent.

FAQ

137 signifie-t-il toujours OOM ?

Le plus souvent oui sur passerelle ; confirmez avec des graphes mémoire.

Pourquoi 143 après déploiement ?

launchd a terminé l’ancien processus pendant le rechargement.

Où est stderr ?

Vérifiez StandardErrorPath dans le LaunchAgent plist.

Quand louer un Mac mini ?

Quand il vous faut le comportement launchd et mémoire fidèle à la prod.

L’archéologie des codes de sortie est fastidieuse mais moins coûteuse que les minutes d’incident. Un Mac mini physique Apple Silicon reproduit le backoff launchd, la compression mémoire et les défauts de descripteurs différents du staging Linux. MacHTML loue des machines avec SSH/VNC pour garder un hôte de diagnostics actif pendant un week-end de release, capturer des flux Console puis tout éteindre le lundi — capacité élastique sans nouveau ticket CapEx.

Le matériel silencieux aide aussi lorsque vous lisez les journaux à voix haute sur visioconférence avec une équipe distribuée.