2026 OpenClaw démon & launchd :
journaux et récupération

01. Trois points douloureux

Faire tourner OpenClaw en continu semble simple jusqu’à ce que les portables dorment, les sessions SSH tombent et les journaux disparaissent sans laisser de trace. Ce guide s’adresse aux opérateurs macOS qui ont terminé une installation de base et ont besoin d’une fiabilité digne de launchd : redémarrages prévisibles, journaux unifiés et une procédure de récupération sans deviner.

1) Processus liés à la session : les exécutions au premier plan dans Terminal ou SSH meurent au hangup ; sans launchd, le service s’arrête quand la machine dort ou que le shell se ferme.

2) Chemins plist obsolètes : après un déplacement de Node ou du CLI, les LaunchAgents pointent encore vers d’anciens binaires—les jobs semblent chargés mais quittent avec des codes de statut opaques.

3) Journaux fragmentés : stdout seul manque les refus TCC et les messages noyau visibles dans log show, ce qui laisse l’analyse au hasard.

Des mises à jour globales du CLI sans recharger l’agent créent aussi un décalage « nouveau CLI, ancien daemon » ; conservez les diffs de plist dans git ou les tickets après chaque changement.

02. Ce que fait openclaw onboard --install-daemon

La commande d’onboarding n’est pas magique ; c’est un échafaudage. Savoir quels fichiers elle touche accélère le débogage quand quelque chose dérive après une mise à jour macOS ou un brew upgrade node manuel.

En pratique elle écrit une plist LaunchAgents utilisateur, aligne les chemins d’environnement et de workspace et enregistre le démarrage automatique après connexion. Installez sous le même utilisateur macOS qui chargera l’agent—mélanger sudo et comptes GUI est un piège fréquent. Commencez par le guide d’installation et de déploiement OpenClaw avant de durcir le daemon.

Sur des Mac loués à la journée, anticipez la perte de données en fin de location : sauvegardez les clés du workspace et des copies de plist ; voyez les cinq points d’attention pour la location Mac à la journée. Injectez EnvironmentVariables si la session GUI et le shell SSH divergent sur PATH ; privilégiez des binaires absolus dans ProgramArguments.

Des Labels ou ports dupliqués entre agents dev et prod provoquent des oscillations ; isolez labels et sockets par environnement. Les invites de confidentialité (accessibilité, contacts) exigent souvent une session GUI unique—un court VNC sur un Mac loué, puis retour à la maintenance SSH.

03. Premier plan contre launchd

Faites correspondre les codes de sortie à la FAQ dépannage des erreurs de commandes. Un KeepAlive mal réglé déclenche des tempêtes de redémarrage—limitez ou corrigez la config au premier plan d’abord.

04. Cinq étapes de récupération

Gardez ces étapes linéaires pendant un incident—passer trop tôt à la réinstallation masque souvent la cause dans une plist que vous recréerez avec la même faute.

1. launchctl list | grep -i openclaw—noter PID et LastExitStatus. Si le job manque, vérifiez que la plist est chargée pour le bon utilisateur GUI (gui/$(id -u)) et pas par erreur dans le domaine système root.
2. log show avec un prédicat sur node/openclaw pour la dernière heure ; joindre l’extrait au ticket. Élargissez le filtre si besoin—certains plantages apparaissent dans les messages com.apple.xpc.launchd qui citent votre label.
3. Ouvrir ~/Library/LaunchAgents/*.plist—valider ProgramArguments, WorkingDirectory, chemins inscriptibles. Développez les tilde mentalement : launchd n’expand pas toujours ~ comme votre shell sans configuration explicite.
4. launchctl bootout du job, corriger la plist, puis bootstrap/load selon la doc de votre version macOS. Sur d’anciennes versions la syntaxe différait (unload/load) ; épinglez les commandes exactes dans votre runbook pour éviter les erreurs de mémoire musculaire sous pression.
5. Revenir en arrière sur OpenClaw ou relancer openclaw onboard --install-daemon ; supprimer les plists en double. Après rollback, exécutez les mêmes tests de fumée qu’après l’installation pour prouver que canaux et webhooks répondent encore.

ls ~/Library/LaunchAgents/ | grep -i openclaw
launchctl list | grep -i openclaw

Traitez l’infrastructure avant l’application : espace disque, synchronisation de l’heure, DNS/TLS—sinon vous traquez la config applicative pour des pannes d’infra. Suivez les changements de plist en contrôle de version pour les Mac de build partagés.

05. Indicateurs et Mac cloud modestes

• 1 : capturer les journaux unifiés dans les 15 minutes suivant l’échec avant rotation.
• 2 : une RAM soutenue >80 % augmente le risque OOM pour les daemons Node—surveillez les SKU 8 Go.
• 3 : des crashs à intervalle court et fixe suggèrent souvent la config ; des intervalles aléatoires plutôt ressources, disque plein ou coupures réseau.

Un Xcode lourd ou des simulateurs qui monopolisent la CPU affament la boucle d’événements—séparez charges ou machines. Pour plus de RAM et des hôtes stables, voir les tarifs MacDate et le guide d’accès distant macOS. Les schémas de prod conteneurisés (le cas échéant) dans le guide de déploiement production en cinq étapes ; le natif macOS reste centré sur launchd.

06. tmux contre Mac dédié à la location

Contrôles de santé hebdomadaires : exportez le statut launchctl list, l’espace libre et la latence API dans une feuille. tmux/screen/nohup résistent partiellement au sommeil mais n’offrent pas de contrôles plist standardisés ; launchd intègre la gestion d’énergie et le comportement au reboot. Pour une récupération prévisible après redémarrage et des journaux consultables, préférez un daemon correctement onboardé—ou isolez sur un Mac loué à la journée pour prouver la stabilité avant engagement.

Terminez la validation d’installation, appliquez cette checklist et croisez avec la FAQ erreurs de commandes. Essais peu coûteux : coût location à la journée contre machine locale. Offres : tarifs.

07. Clés plist qui comptent pour les daemons OpenClaw

Au-delà de Label et ProgramArguments, plusieurs clés changent la fiabilité. WorkingDirectory doit exister avant que launchd ne démarre le job ; si l’onboarding a créé un lien symbolique ensuite rompu, l’agent quitte immédiatement. RunAtLoad contrôle si le job démarre dès le chargement de la plist—utile sur serveur, parfois surprenant sur portable. ThrottleInterval empêche les boucles de crash de saturer la CPU ; associez-le à de vrais correctifs plutôt qu’à du masquage d’erreurs. EnvironmentVariables doit dupliquer ce dont votre shell interactif dépendait (PATH, NODE_OPTIONS, surcharges d’hôte API). Documentez chaque clé dans votre wiki interne pour que les montées de version ne suppriment pas silencieusement des variables requises.

Si vous maintenez plusieurs environnements, namespacéz agressivement les valeurs de Label. Les labels dupliqués font échouer la seconde plist discrètement ou la font entrer en conflit avec la première. Utilisez des préfixes du type com.votreorg.openclaw.prod versus .staging et vérifiez avec launchctl print gui/$(id -u) sur macOS récent pour voir le graphe effectif.

08. Journaux : Unified Logging, fichiers et rotation

Ne vous fiez pas seulement à la sortie Terminal une fois daemonisé. Privilégiez log stream ou des prédicats log show pendant les incidents, et envisagez StandardOutPath et StandardErrorPath dans la plist pour des journaux texte durables—attention à la croissance disque et à la rotation ou troncature avec un outil type logrotate. Les jetons sensibles peuvent apparaître dans stderr ; verrouillez les permissions et anonymisez avant partage externe.

Corrélez les horodatages launchd avec les journaux applicatifs d’OpenClaw s’ils existent. Quand la réutilisation de PID embrouille la chronologie, incluez l’UUID de session de boot depuis les en-têtes log show --style syslog. Sur Mac loués, copiez les journaux hors instance avant libération car les disques éphémères peuvent ne pas survivre au locataire suivant.

09. Veille, alimentation et Mac cloud « sans tête »

Les portables dorment ; beaucoup de Mac cloud sont configurés comme postes de travail. Si Power Nap ou la veille s’activent, le réseau en arrière-plan peut se mettre en pause de façon imprévisible. Pour des agents toujours actifs, désactivez la veille sur secteur via pmset lorsque la politique le permet, ou utilisez caffeinate avec parcimonie en attendant de corriger l’énergie. Documentez qui peut modifier les profils d’alimentation—des réglages bien intentionnés rétablissent la veille et tuent les jobs de nuit silencieusement.

Sur des Mac mini hébergés en datacenter, confirmez le comportement thermique et des ventilateurs sous CPU Node soutenue. La limitation peut ressembler à une latence « aléatoire » sur les webhooks sortants même si le processus ne plante jamais.

10. Autorisations, TCC et invites réservées à la GUI

Les fonctionnalités OpenClaw qui touchent à l’enregistrement d’écran, à l’accessibilité ou aux calendriers locaux peuvent exiger des approbations Transparency, Consent, and Control qui n’apparaissent qu’en session graphique. Un pur daemon SSH peut rester bloqué en attendant une saisie que vous ne pouvez pas fournir à distance. Effectuez le premier consentement via VNC une fois, exportez une checklist des droits accordés et capturez la politique TCC si votre équipe sécurité l’autorise. Si vous recréez des utilisateurs ou migrez des plists, attendez-vous à répéter certaines invites.

Sous Apple Silicon avec Rosetta, assurez-vous que la plist pointe vers le binaire d’architecture voulu ; des arbres Node arm64/x86_64 mélangés ont produit des mystères « ça marche en shell de connexion, échoue sous launchd » parce que le shell chargeait des hooks nvm que le daemon n’hérite pas.

11. Cadence de mise à jour et retour arrière

Traitez les mises à jour OpenClaw comme toute autre dépendance de production : épinglez les versions, lisez les notes de version, mettez en scène d’abord sur un Mac non prod. Après upgrade, launchctl bootout puis recharge pour prendre le nouveau chemin binaire. Conservez l’ancien arbre node_modules ou une archive du lockfile pour un rollback rapide. Automatisez un test de fumée—point de santé ou ping CLI—qui doit réussir avant que la supervision ne marque le daemon comme sain.

Pour répéter ces étapes sur du matériel isolé sans risquer votre portable, les plans Mac à la journée permettent d’essayer à bas coût les éditions de plist, les invites de permission et les cycles reload launchd. Quand le daemon tient une semaine de charge synthétique, promouvez le même modèle de plist vers l’infra partagée. Vous réduisez le bruit de pagere et gardez OpenClaw réactif pour les flux qui comptent.

12. Crochets de supervision et contrôles synthétiques

Les daemons de production méritent la même observabilité que les API. Exposez une commande de santé légère—même un openclaw status trivial ou un ping HTTP—que votre pile de supervision peut appeler chaque minute. Alerte après trois échecs consécutifs, pas à chaque à-coup, pour limiter le flapping. Couplez les contrôles de processus à des alertes basées sur les journaux lorsque Unified Logging contient des signatures d’erreur difficiles à refléter par codes de sortie.

Planifiez chaque nuit une conversation synthétique ou une invocation d’outil qui exerce les canaux importants (chat, e-mail, système de fichiers). Enregistrez durée et succès ; une lenteur progressive précède souvent les pannes dures quand fuites mémoire ou limites de descripteurs montent. Gardez les tableaux de bord près de ceux qui surveillent la ferme de build pour éviter une seconde connexion d’astreinte.

Documentez les niveaux de gravité : le jaune peut signifier redémarrer l’agent ; le rouge bascule vers un Mac de secours ou un rollback de release. Liez chaque niveau à des commandes concrètes (launchctl kickstart, reload plist, rétrogradation de paquet) pour que les pages de minuit restent exécutables sous stress. Organisez un game day trimestriel où quelqu’un casse volontairement la plist en staging et l’équipe s’entraîne contre la montre—les trous de doc apparaissent vite.

Intégrez l’inventaire d’actifs : quels numéros de série ou instances louées hébergent OpenClaw, quelle version de plist tourne, qui valide les upgrades macOS. La dérive de configuration sur une flotte est plus pénible qu’un portable mal réglé, mais les primitives launchd restent les mêmes—à plus grande échelle. Ajoutez au runbook un paragraphe sur les chemins d’escalade et les responsables sauvegarde pour éviter les rôles flous lors d’incidents prolongés.

13. Posture de sécurité pour agents toujours actifs

Les daemons en ligne héritent des privilèges du compte qui les charge. Traitez ce compte comme une identité de service : moindre privilège sur disque, pas de droits admin inutiles, secrets dans le trousseau macOS ou un coffre—pas en clair dans des plists versionnées. Faites tourner les clés API au même rythme que les jetons CI et documentez qui peut lancer une rotation sans rebooter tout l’hôte.

L’egress réseau doit être explicite. Si OpenClaw n’a besoin que de quelques points de terminaison, imposez-les via pare-feu hôte ou proxys sortants lorsque la politique le permet. Journalisez distinctement les échecs de connexion et les erreurs applicatives pour distinguer permissions et micro-coupures DNS. Sur des flottes Mac distantes, alignez VPN ou Zero Trust avec les régions touchées par votre automation pour éviter des géoblocages surprises.

Sauvegardez le snapshot plist et environnement à chaque changement de version. Une archive de ~/Library/LaunchAgents, des profils shell pertinents et une sortie launchctl print expurgée donnent une base reproductible aux auditeurs et à vous-même dans six mois. Ajoutez une ligne de journal : date, opérateur, motif, commande de rollback—la paperasse ennuyeuse évite le débogage héroïque plus tard.

Lorsque les assistants exécutent des outils ou scripts, limitez l’accès fichiers. Répertoires de travail dédiés, pas de chemins world-writable, contrôles d’intégrité périodiques si les binaires sont modifiables par l’utilisateur. Si vous partagez un Mac loué entre expériences, effacez l’état entre locataires ou utilisez des comptes séparés pour que les LaunchAgents n’héritent pas de jetons d’une autre équipe.

La réponse aux incidents doit inclure un interrupteur d’urgence : étapes documentées pour décharger l’agent, révoquer les identifiants et informer les parties prenantes en cas de compromis suspect. Exercez l’interrupteur en staging pour ne pas inventer les commandes pendant l’événement réel. Sécurité et fiabilité partagent la même fondation—un comportement launchd prévisible en conditions normales et adverses.

Relisez cette checklist après chaque upgrade macOS majeur : dialogues d’autorisation, règles de runtime durci et Gatekeeper peuvent bouger discrètement pendant que votre plist reste inchangée. Intégrez cette relecture à votre checklist de release, pas à une hygiène optionnelle. En complément, vérifiez périodiquement si les nouvelles fonctions de sécurité macOS déclenchent des invites supplémentaires pour les processus d’arrière-plan qui pourraient surprendre votre maintenance à distance.