OpenClaw MCP-Waisenprozesse auf gemietetem Mac mini: Exit-Hygiene und launchd-Recovery (2026-05-19)

Teams, die OpenClaw mit MCP-stdio-Servern auf gemieteten Mac mini M4 in den Regionen Hongkong, Japan, Korea, Singapur oder USA (ProxyMac) betreiben, sehen mitunter steigende RSS im Leerlauf, zusätzliche node-Zeilen oder flaky Tools nach einem Gateway-Upgrade. Dieses Feldheft vom 19.05.2026 trennt Waisenansammlung von JSON-Puffer-Hängern, liefert eine fünfspaltige Operator-Matrix und ein launchd-freundliches Neun-Schritte-Runbook. Vertiefung über parallele Agenten, stdio-Buffering und Gateway-Recovery.

Symptome: Prozesstabelle driftet vor dem Swap

Öffentliche Berichte beschreiben Node-Kinder, die zehn MB große RSS-Brocken halten, obwohl der Elternteil weg ist. Auf Bare-Metal ohne Nachbarn zeigt sich das sofort in top.

• Zeilendrift: pgrep -lf mcp liefert nach einer stillen Nacht mehr Treffer als nach Kaltstart.
• Staffel-Latenz: erste Tool-Calls ok, später Stau; klassischer Zombie-Leser auf der Pipe.
• Versions-Skew: CLI neu, LaunchAgent-Gateway alt.
• False „Model down“: Provider-Latenz ok, lokaler Fork voll.

Ursachen: warum stdio MCP klebrige Bäume erzeugt

Stdio vermeidet wilde TCP-Ports, übernimmt aber POSIX: solange eine Schreibseite offen ist, kein EOF. npx kann Enkel ohne Shell zurücklassen. LaunchAgent-Umgebungen sind magerer als interaktive Shells—kurze Restart-Schleifen wirken wie CPU-Angriffe.

Ergänzend ulimit & Speicher: die oft zitierte weiche Grenze von 2560 Dateideskriptoren reicht nicht, wenn jeder Tool-Call mehrere Pipes öffnet.

Operator-Matrix (Signal → Aktion)

Primärsignal	Erste Aktion (Reihenfolge)	Archivdaten	Rollback	Owner
~200 MB RSS in ~20 min ohne Last	Zuerst ps -o pid,ppid,rss,command exportieren	PPID-Kette + JSONL-Zeitstempel	Kein kickstart vor Eltern-Label	Plattform-SRE
Doppel-LISTEN Admin-Port	Gateway-Recovery (ein Listener)	lsof -nP -iTCP:18999 -sTCP:LISTEN	Konkurrierendes plist bootout	Automation Lead
429-Stürme, niedrige CPU	Parallelität senken (Parallel-Leitfaden)	429 pro 5-Minuten-Fenster	Altes maxConcurrentTasks	FinOps
Flache RSS, Tools hängen	PTY/Buffer prüfen, kein sofortiges SIGKILL	Kurzer dtruss-Sample (Policy)	Unbuffer-Experimente zurück	Client-Engineering

Operatoren sollten jede Intervention wie einen kleinen Change behandeln: vor dem ersten Signal dokumentieren Sie Baseline-Zahlen (Load Average, freier Speicher auf dem APFS-Container, Anzahl offener TCP-Verbindungen zum LLM-Endpunkt). Wenn die RSS-Kurve monoton steigt, aber die Anzahl der Tool-Aufrufe pro Minute unter 5 bleibt, liegt der Fehler fast immer lokal—nicht beim Inference-Anbieter. Vergleichen Sie außerdem die Uptime des Gateway-Prozesses mit der Uptime der MCP-Kinder: große Differenzen sind ein starker Hinweis auf verwaiste Subprozesse.

Auf einem bei ProxyMac gemieteten Mac mini M4 in Hongkong, Tokio, Seoul, Singapur oder den USA lohnt es sich, regionale Latenz mit Prozesshygiene zu koppeln: ein zusätzlicher Ozean-Sprung zwischen Tool und API wirkt wie „langsames Modell“, obwohl nur die lokale Pipe blockiert. Nutzen Sie deshalb nach jedem Incident ein kurzes Postmortem-Template mit Zeitachse (UTC), betroffenen PID-Ketten, betroffenen MCP-Server-Namen und dem exakten launchctl-Label—das verkürzt die nächste Eskalation um Stunden.

Wenn mehrere Teams dieselbe Mini-Instanz teilen, definieren Sie schreibgeschützte Diagnosebefehle, die jeder ausführen darf (ps, pgrep, lsof mit eingeschränkten Pfaden), und halten Sie destruktive Schritte einem kleinen On-Call-Kreis vor. Dokumentieren Sie außerdem, welche Node-Major-Version das Gateway erwartet und welche Version jeder MCP-Server tatsächlich startet—Major-Sprünge erklären oft plötzliche ABI-Fehler, die wie hängende Prozesse aussehen.

Neun-Schritte-Clean-Run (SSH)

1. Wartungsfenster kommunizieren (auch 90 s).
2. Beweise: letzte 500 Gateway-Logzeilen + launchctl print gui/$UID-Ausschnitt.
3. Eingang einfrieren: Webhooks/Scheduler pausieren.
4. PPID-Karte: kein kill -9 am LaunchAgent-Gateway vor Klassifikation.
5. SIGTERM-Welle: 15 s warten, neu zählen.
6. SIGKILL nur mit verifiziertem argv.
7. Gateway recyceln: launchctl kickstart -k oder bootout/bootstrap laut Hersteller.
8. Smoke: zwei read-only Tool-Calls, RSS in 10 min normalisieren.
9. Postmortem: wöchentlich → PPID-CSV + Link zu diesem Artikel.

launchd-Recycle: ThrottleInterval & Co.

ThrottleInterval, KeepAlive und SuccessfulExit steuern die Restart-Aggressivität. Nur Node tauschen, während alte stdio an toten PTYs hängen, erzeugt ein „gesundes“ Gateway mit zufällig kaputten Tools. launchctl print auf EffectiveUserID prüfen.

TCC/Schlüsselbund einmalig per VNC, dann wieder headless laut Hilfe. GUI-Genehmigungen plus unbeaufsichtigte launchd-Zyklen verdoppeln oft MCP-Server.

Zusätzlich lohnt sich ein Blick auf vm_stat und memory_pressure: wenn der Kompressionswert steigt, während gleichzeitig die Anzahl der node-Prozesse wächst, interpretieren Sie das nicht als „mehr Intelligence“, sondern als wachsende Prozessfläche. Halten Sie für jede Umgebung ein Referenz-Snapshot nach sauberem Boot bereit—ohne diesen Nullpunkt verschwenden Teams Stunden mit Debatten, ob 1,2 GB RSS „normal“ sei. Binden Sie schließlich Ihre Housekeeping-Schritte an die gleiche Versionskontrolle wie den OpenClaw-Stack: wenn openclaw.json per Git verwaltet wird, sollten auch die Notfall-Skripte (keine generierten Helfer, nur dokumentierte Befehle) im Repo mitreviewt werden, damit niemand aus Versehen killall node auf einem geteilten Host ausführt.

Prävention: Parallelität, Timeouts, Blast-Radius

• Warteschlangentiefe/-alter loggen; paralleles OpenClaw als Muster.
• Harte Timeouts: Netzwerk-Tools start 120 s, leichte Stats 15 s (Produktkeys beachten).
• Getrennte Arbeitsverzeichnisse pro Automation-Persona.
• Lab-Mini vs. Prod-Mini; Region HK/JP/KR/SG/US über Preise wählen.

Richten Sie schließlich einen wöchentlichen Diff-Check ein: gleichen Sie die Liste der konfigurierten MCP-Server mit den tatsächlich laufenden argv-Zeilen ab. Jeder Server, der in der Konfiguration fehlt, aber auf dem Host lebt, ist ein Sicherheits- und Hygienedefekt; jeder Server in der Konfiguration ohne laufenden Prozess nach einem angekündigten Deploy deutet auf fehlgeschlagene Starts hin—beides verdient ein Ticket, keinen stillen Workaround.

FAQ

Warum laufen MCP-stdio-Server weiter, wenn das Gateway gestoppt wurde? Harte Abstürze, unvollständige SIGTERM-Ketten oder via npx gestartete Enkel-Node-Prozesse können ohne Zwischen-Shell weiterleben. KeepAlive-LaunchAgents starten ein neues Gateway, während alte Pipe-Deskriptoren offen bleiben—Tools wirken zufällig kaputt, obwohl die Modelllatenz gesund bleibt.

Darf ich Waisen-MCP-PIDs in Produktion auf einem ProxyMac-Mini killen? Zuerst SIGTERM, ps/lsof-Beweise sichern, Kommandozeile prüfen, erst dann SIGKILL. Auf geteilten Hosts offene Dateien prüfen, um Kollegensessions nicht zu beenden. Nach dem Neustart mit lsof verifizieren, dass nur ein LISTEN auf dem Admin-Port liegt.

Unterschied zu stdio-Zeilenpuffer-Hängern? Buffering zeigt oft partielle JSON-Zeilen bei flacher CPU. Waisenansammlung zeigt steigende RSS und zusätzliche node-Prozesse im Leerlauf. Ersteres braucht PTY/Unbuffer-Flags, letzteres Parallelitätsdeckel, Timeouts und Gateway-Recycle-Disziplin.

Warum ProxyMac Mac mini MCP-Nebenwirkungen bündelt

Jeder MCP-Call vermehrt Forks und FDs. Apple Silicon M4 liefert Single-Thread-Spielraum, macOS spiegelt Desktop-Automation, HK/JP/KR/SG/US nähert SaaS-Regionen an. Mietmodell = Wegwerf-Lab-Mini auf derselben Preis-Seite wie Prod, ohne CAPEX für Softwarehygiene. Prozesse mit Hilfe SSH/VNC abstimmen.