OpenClaw launchd: ThrottleInterval, KeepAlive und Health-Probes – Matrix 2026 auf gemietetem Mac mini

Plattformingenieure, die OpenClaw als LaunchAgent auf einem gemieteten Apple-Silicon-Mac mini von VmMac betreiben, erben subtile Defaults: ThrottleInterval verbirgt Crash-Schleifen, KeepAlive belebt vergiftete Prozesse, und SuccessfulExit passt nicht immer zu Node-Gateways während Upgrades. Diese Matrix 2026 benennt sichere Kombinationen, erklärt falsch-positive Neustart-Stürme, listet headless Health-Probe-Muster und bindet Observability an Parität in Hongkong, Japan, Korea, Singapur und den Vereinigten Staaten. Lesen Sie parallel Gateway-Wiederherstellung, Staging vs. Produktion und strukturierte Logs und Plattenrotation, damit plist-Änderungen kein Ratespiel werden.

Pfade und Erstausrollung: Installations- und Deploy-Guide; Zugang: Hilfe; dedizierte Canary-Hosts: Preise. Korrelieren Sie Spotlight/mds-Spitzen mit Indexing- und CI-Plattenmatrix, bevor Sie OpenClaw beschuldigen.

Warum launchd-Richtlinie wichtiger ist als die Node-Binärversion

Ein perfektes OpenClaw-Semver nützt wenig, wenn launchd das Gateway alle 12 Sekunden neu startet, weil Ihr Health-Check LLM-Latenz für Tot hält. plist-Schlüssel sind Teil des SLA: Sie definieren, wie das OS Erfolg, Fehler und Backoff interpretiert. Ohne Hypervisor-Supervisor ist bei VmMac launchd der Supervisor.

Node-Gateways erben macOS-Signalsemantik: SIGTERM beim Deploy muss HTTP-Server schließen, strukturierte Logs flushen und beenden, bevor launchd zu SIGKILL eskaliert. Ignoriert der Prozess SIGTERM wegen hängender WebSockets, sehen interaktive Shells „erfolgreiche“ manuelle Restarts, während Agenten flaky wirken. Dokumentieren Sie die erwartete Signalleiter im selben README wie das Node-LTS-Pin und proben Sie auf einem Wegwerf-VmMac-Mini, bevor Sie Produktions-plists anfassen.

ThrottleInterval ersetzt keine Bugfixes—es ändert nur die Lautstärke von Fehlern. Kombinieren Sie OS-Backoff mit anwendungsseitigen Circuit Breakern, damit eine falsche Modellkonfiguration nicht alle Regionen gleichzeitig CPU-sättigt. Standard soll identische Zahlen in Hongkong, Japan, Korea, Singapur und den USA sein; dokumentierte Ausnahmen nur für Latenzexperimente.

• ThrottleInterval begrenzt Neustarthäufigkeit, kann aber anhaltende Teilausfälle maskieren.
• KeepAlive hält Daemons resident, erschwert aber Draining-Upgrades.
• ExitTimeOut setzt das Budget für graceful Shutdown vor SIGKILL.

Matrix: ThrottleInterval vs. KeepAlive vs. ExitTimeOut

Ziel	Primärer Hebel	Risiko	Mitigation
Crash-Schleifen stoppen	ThrottleInterval ≥ 30 s	Langsamere Recovery nach echten Crashes	Externes Paging auf Exit-Code
Immer-an-Gateway	KeepAlive true + SuccessfulExit false	Respawn bei Absichtsshutdown	Separates Maintenance-Label
Graceful Drain	ExitTimeOut 25–40 s	Hängender Shutdown blockiert Restart	Watchdog-SIGKILL nach Budget
Donnernde Herde nach Reboot vermeiden	Gestaffeltes StartCalendarInterval oder Random-Sleep im Wrapper	Verzögerte Readiness	Health-Gate wartet auf Abhängigkeiten

Co-Location mit anderen launchd-Agenten derselben Session: Erwägen Sie plist-Nice und LowPriorityIO, damit ein Log-Shipper den Event-Loop des Gateways nicht aushungert. Das ersetzt keine Kapazitätsplanung, kauft aber Minuten in partiellen Ausfällen—oft genug, damit On-Call ThrottleInterval bewusst weitet statt gegen fehlerhafte Health-Wrapper zu kämpfen.

Falsch-positive Neustart-Stürme: Symptome und Ursachen

Stürme beginnen oft, wenn Health localhost trifft, während das Gateway nach Plattenstress noch Module lädt. Ein weiteres Muster: Spotlight oder mds verlängern Cold-Start und überschreiten Probe-Timeouts—korrelieren Sie mit Indexing-Richtlinie.

Dependency-Flapping: Prüft die Probe externe SaaS vor Loopback-Bereitschaft, markieren Routing-Glitches in Japan oder Singapur das Gateway fälschlich ungesund. Schichten Sie Probes: zuerst Loopback, optional externe Canary mit lockereren Timeouts, damit launchd nicht an fremde SLAs gekoppelt ist.

Volle Platten erzeugen grausame Crash-Loop-Illusionen: JSONL bis ENOSPC, Non-Zero-Exit, KeepAlive weckt den Prozess, Logs scheitern sofort wieder—oft schneller als ThrottleInterval kühlt. Spiegeln Sie Platten-Leitplanken aus strukturierter Log-Rotation, damit Restarts aus den richtigen Gründen langsamer werden.

Headless-Health-Probes ohne VNC

Nutzen Sie einen kleinen Wrapper, der den Health-Port auf Loopback per curl anspricht—TLS-Verify nur dort abschalten—oder besser die CLI-Status-Unterbefehle von OpenClaw. Loggen Sie nach der Probe HTTP-Status, TLS-Handshake-ms und PID, damit On-Call „Prozess lebt, aber klemmt“ von „Prozess tot“ unterscheidet.

Wo möglich, senden Sie einen synthetischen X-Probe-Trace-Id-Header und echoen Sie ihn in Gateway-Logs, um Probe-Fehler mit langsamen Queries zu vernähen. Diese Korrelation beendet mehr Sev2s als plist-Tweaks, weil sie beweist, ob launchd rational reagierte.

curl -fsS --max-time 3 http://127.0.0.1:18789/health || exit 1

Achtstufige Tuning-Leiter für 2026

1. Sieben Tage Baseline-Exit-Codes vor plist-Änderung erfassen.
2. ThrottleInterval setzen, um Muster unter 20 s zu stoppen.
3. ExitTimeOut an dokumentierte Graceful-Shutdown-SLA angleichen.
4. Strukturierte Logs für jeden Neustartgrund ergänzen.
5. 72-Stunden-Canary in einer VmMac-Region.
6. Neustarts über HK, JP, KR, SG, US vergleichen.
7. Rollback-plist im Git-Tag launchd-YYYYMMDD dokumentieren.
8. Vierteljährliches Game Day: kill -9 und Recovery messen.

Zwischen Schritt vier und fünf: Einfrieren von Feature-Arbeit am Canary-Label für 72 Stunden, selbst wenn Metriken grün sind—Wochenend-Traffic enthüllt viele Stürme. Speichern Sie sample- und footprint-Snapshots im Canary-Fenster für speicherbezogene Regressionen zwischen Regionen.

Anbindung an Gateway-Recovery-Runbooks

Recovery-Artikel beschreiben was neu zu starten ist; diese Matrix beschreibt wann das OS für Sie neu starten soll. Widersprechen sich Zahlen, gewinnen kill -9-Gewohnheiten Oberhand. Halten Sie identische numerische Knöpfe in Staging und Prod gemäß Staging-Isolation, damit Promotions diffbar bleiben.

Observability-Tabelle: Felder pro Neustart

Feld	Zweck
launchd_exit_status	OOM vs. sauberer Exit
uptime_s	Säuglingssterblichkeits-Schleifen
rss_mb	Leaks vor SIGKILL korrelieren
fds_open	Descriptor-Leaks, verstärkt durch KeepAlive
last_http_5xx_ts	Upstream-Ausfälle von lokalem Tod trennen

Schicken Sie diese Felder als JSON-Zeilen in dieselbe Sink wie Gateway-Requests, damit SREs von „launchd hat den Job neu gestartet“ zu „RSS überschritt 1,2× Basislinie“ pivotieren können. Konsistente Namen in Hongkong, Japan, Korea, Singapur und den Vereinigten Staaten schlagen perfekte Kardinalität in der ersten Iteration.

FAQ: launchd und OpenClaw auf Mac mini

LaunchDaemon statt LaunchAgent? Nur nach explizitem Security-Review—Agenten erben TCC-Grenzen, von denen Sie abhängen können.

Pro Region tunen? Nur mit schriftlichen Ausnahmen; Default ist Parität.

Upgrades? ThrottleInterval während npm-Migrationen temporär weiten.

Ist SuccessfulExit false immer „bei jedem Exit neu starten“? Effektiv ja für die meisten Gateways—koppeln Sie Anwendungs-Exit-Codes für Drain-vs.-Crash, sonst kämpfen Blue/Green-Deploys mit launchd.

Health als root? Bevorzugen Sie denselben Nutzerkontext wie das Gateway; root nur für eng begrenzte read-only-Probes.

Alerts während Wartung? Wartungsdatei im Wrapper prüfen, automatisch ablaufen lassen.

Warum Mac mini M4 und VmMac zu Always-on-Gateways passen

Mac mini M4 liefert genug Dauerleistung für gelegentliche Cold Starts ohne aggressive Probes zu triggern; vereinheitlichter Speicher reduziert OOM-Flaps gegenüber überbuchten VPS. VmMac platziert Gateways in Hongkong, Japan, Korea, Singapur und den Vereinigten Staaten nahe Nutzern und Datenresidenz—zweiter Mini für Canary-plists ohne Produktions-Neustartsemantik zu riskieren.

Mieten verkürzt Feedback, wenn Apple macOS-Sicherheitspatches subtil launchd ändern: plist-Matrix snapshotten, Patch auf Nicht-Prod-Mini, Health-Harness wiederholen, dann Kundenautomatisierung anfassen. Günstiger als eine nächtliche Page durch undokumentierte Restart-Politik.