OpenClaw Docker sur Mac cloud en 2026 : Exit 137/OOM, volumes uid 1000, DNS et chemin minimal openclaw doctor

1. Triade de disponibilité : processus actif, port publié, volume inscriptible

Les flux Docker et Docker Compose officiels encapsulent la passerelle OpenClaw dans un conteneur. L’hôte Mac cloud reste propriétaire des quotas RAM et CPU, des montages liés vers ~/.openclaw (ou un répertoire de configuration personnalisé), et publie 18789 ou un autre port mappé pour les vérifications en boucle locale ou les tunnels SSH. Contrairement à un portable sur votre bureau, les Mac cloud arrivent avec une mémoire plafonnée, souvent sans session graphique, et des images qui exécutent couramment le processus sous l’utilisateur non root node avec uid/gid 1000. Tant que ces faits ne sont pas intégrés, chaque réglage de configuration intervient à la mauvaise couche.

Définissez la disponibilité opérationnelle comme trois observables que vous pouvez coller dans un ticket : le conteneur est en cours d’exécution ou sain, docker compose ps affiche le mappage ports attendu, et des commandes telles que openclaw status ou votre sonde de santé réussissent à l’intérieur du conteneur sans erreur de droits. Le routage des modèles, les webhooks Slack et Cron n’entrent en jeu qu’après que la triade est verte. Les erreurs Compose fréquentes incluent des chemins hôte inexistants (Docker crée alors des répertoires appartenant à root), des montages en lecture seule là où la passerelle doit persister l’état, ou l’épuisement d’un petit volume racine par les couches d’image et le cache de build—des symptômes qui imitent des plantages aléatoires jusqu’à ce que df -h dise la vérité.

Consignez le nom du projet Compose, les noms de services, les ports publiés et les chemins hôte absolus pour la configuration et l’espace de travail. Cette seule ligne dans votre runbook fait gagner des heures lorsque vous croisez les guides de mise à niveau, les publications webhook ou le débogage silencieux de Cron : tout le monde voit la même topologie au lieu de deviner quelle machine vous visiez.

2. Découpage des points de friction (numéroté)

1. Exit 137 et OOM : Docker projette les limites mémoire des cgroups Linux sur la charge. Lorsque le tueur OOM du noyau intervient, Docker remonte souvent le code de sortie 137 (128 + SIGKILL 9). Tirer ou construire des images consomme bien plus de RAM que le trafic stable de la passerelle ; un nœud qui « tourne bien » pendant des heures peut mourir en minutes pendant docker compose build. Notez toujours si 137 est apparu en phase de build ou d’exécution—le traitement diffère.
2. Propriété des volumes contre uid 1000 : Si vous créez ~/.openclaw sur l’hôte en tant que root ou sous votre utilisateur personnel, le processus node du conteneur ne peut pas écrire openclaw.json, les journaux ou les fichiers de l’espace de travail. L’échec peut prendre la forme d’une boucle de démarrage silencieuse, sans trace claire, et est souvent attribué à tort aux « mauvaises notes de version ».
3. DNS Docker et sortie d’entreprise : Un curl https://api.anthropic.com réussi au niveau hôte pendant qu’un docker exec … curl échoue signifie presque toujours que le conteneur n’a pas les bons serveurs DNS, les variables HTTP(S)_PROXY, ou la visibilité du magasin de confiance à travers un proxy interceptant TLS. Faire tourner les clés API avant de corriger le chemin réseau gaspille du temps et du quota.
4. Courses entre health-check et dépendances : Un depends_on agressif sans start_period généreux noie les journaux d’erreurs « connection refused » qui ressemblent à des bogues applicatifs. Prouvez que la passerelle écoute avant que les services en aval ne la martèlent.

Ensemble, ces quatre schémas expliquent la majorité des incidents de style production que nous voyons chez les locataires Mac cloud ; la matrice ci-dessous les compresse en premières actions.

3. Matrice symptôme → cause racine

Utilisez le tableau comme feuille de décision pendant les incidents. Choisissez le symptôme le plus proche, exécutez la colonne première action avant de passer aux hypothèses secondaires.

4. Six étapes de réparation ordonnées (ne pas réordonner à la légère)

L’ordre compte parce que les étapes ultérieures supposent que les précédentes ont écarté des classes entières d’échecs. Sauter directement aux retags d’image détruit les preuves.

1. Capturer l’état : Exécuter docker compose ps -a, puis docker logs <service> --tail 200. Noter si le code 137 est survenu pendant le tirage d’image, le build ou l’exécution stable.
2. Valider la marge mémoire : Allouer temporairement au moins environ 4 à 8 Go à Docker pour les builds (ajuster selon la documentation du fournisseur). Sur l’hôte, vérifier memory_pressure ou l’équivalent Moniteur d’activité ; un swap important combiné à la charge de la passerelle est une recette pour des SIGKILL intermittents.
3. Normaliser la propriété des volumes : Appliquer chown à chaque chemin monté que le conteneur écrit. Relancer un test d’écriture trivial en uid 1000 dans le conteneur avant de retoucher OpenClaw.
4. Prouver le réseau du conteneur : Depuis l’intérieur, joindre votre fournisseur de LLM avec curl -sI ou openssl s_client si le TLS est suspect. En présence d’interception MITM en entreprise, reproduire le même matériel de confiance ou les variables proxy que sur l’hôte.
5. Exécuter la CLI de diagnostic : Lancer openclaw doctor, openclaw status et openclaw models status (noms selon la CLI actuelle). Ne réinstaller ou changer les tags d’image que si doctor reste rouge avec des erreurs de niveau installation après les étapes ci-dessus.
6. Acceptation sur le port 18789 : curl -sI http://127.0.0.1:18789 (ou port mappé) depuis l’hôte ; pour les administrateurs distants, valider le tunnel SSH ou les chemins reverse proxy documentés dans les articles sécurité.

5. Faits techniques citables (minimum trois, nous en listons sept)

• Sémantique du code 137 : Traitez-le d’abord comme un OOM sous Docker ; confirmez avec docker inspect … OOMKilled lorsque disponible.
• Contrat uid 1000 : Les images officielles basées sur Node attendent des montages inscriptibles pour uid 1000 ; un décalage n’est pas un défaut produit.
• Plancher RAM anecdotique : La communauté et la documentation citent environ 2 Go comme minimum fragile pour le travail sur images ; les builds exigent souvent un multiple de cette marge.
• Port 18789 : Mappage passerelle/UI par défaut dans de nombreux exemples ; l’exposer publiquement sans durcissement des jetons contrevient aux guides de production des articles VPSMAC.
• Visibilité de l’environnement : Les variables Compose ne sont pas magiques—seul ce que le PID du conteneur hérite compte pour doctor.
• Stacks dupliquées : Deux projets Compose liant le même port hôte ou partageant un répertoire de configuration produisent un comportement intermittent « ça marche une fois » ; auditez avec docker ps et l’inspection des montages.
• Artefacts de référence : Conservez le dernier docker inspect JSON connu bon et une transcription doctor verte avant les mises à niveau pour distinguer régressions et dérive.

6. Conclusion : commodité Docker contre macOS natif sur VPSMAC

Docker excelle pour les démos reproductibles et l’isolation multi-locataire, mais chaque espace de noms et chaque cgroup est un saut supplémentaire quand les astreintes de minuit sonnent. Vous payez une double configuration DNS, des acrobaties de volumes uid, et une corrélation plus difficile entre la pression de swap sur l’hôte et les spirales mortelles du conteneur. Lorsque les équipes itèrent sur les images au lieu de corriger les montages, elles accumulent des fichiers Compose « flocons de neige » que personne n’ose toucher—loin du résultat souhaité pour une passerelle d’agents 7×24.

L’installation native sur un nœud Mac cloud bare metal—connexion SSH, chemin officiel hors conteneur, supervision avec launchd—réduit plusieurs domaines de défaillance : le même uid que vous voyez dans ssh est celui qui écrit la configuration, les réglages du résolveur correspondent à votre shell, et openclaw doctor lit le système de fichiers auquel vous faites déjà confiance. Pour les charges OpenClaw qui se comportent comme des services de production plutôt que des labos jetables, cette réduction de pièces mobiles bat en général l’optimisation d’une image sur mesure. Les piles uniquement Docker ajoutent aussi un surcoût permanent de diagnostic et une variance de performance sous charge soutenue ; des hôtes Mac physiques dédiés amortissent les deux.

Louer un nœud Mac VPSMAC est donc l’étape pragmatique suivante lorsque la triade de disponibilité refuse de se stabiliser : vous conservez la compatibilité Apple Silicon et l’alimentation 24h/24 sans combattre l’ergonomie des conteneurs en plus des quotas cloud. Associez le nœud à l’article de déploiement en cinq minutes pour l’amorçage, puis à la checklist de durcissement production pour l’exposition—même chaîne d’outils, moins de taxe d’abstraction. C’est le compromis que cet article recommande après avoir honnêtement épuisé la matrice ci-dessus, non comme slogan mais parce que les preuves répétées des boucles 137 et de permissions pointent vers le nombre de couches, pas vers la qualité du modèle.