Onboard läuft, aber CLI oder Dashboard bleiben lange auf Gateway not ready / not ready—das passiert meist bevor der Prozess wirklich lauscht, eine andere Schicht als der On-Site-Artikel gateway closed (1000) (Sessions, Scopes, Token). Dieser Text liefert Plattformteams den kürzesten Weg: mit sieben Punkten Ports, Speicher, Timeouts, Images und Volumenrechte klären, per Bare-Metal-systemd vs. Docker-Tabelle die richtige Logfläche wählen, dann ein Sechs-Schritte-Runbook (inkl. openclaw doctor und Beispielbefehle) und parallel Installationsüberblick, Docker-Produktion sowie Observability lesen.
not ready heißt meist: die Steuerungsebene hat noch kein erfolgreiches Listen, bereite Abhängigkeiten oder bestandene Healthchecks gesehen; das ist nicht dasselbe wie Policy-Kick nach aufgebautem WebSocket—dafür zuerst closed (1000). Die sieben Punkte sind eine Plattform-Selbstanalyse in der ersten Woche nach der Installation.
Port durch alten Prozess oder anderen Dienst belegt: nach Upgrades oder wiederholtem docker compose up kann ein alter Gateway auf dem Host denselben Port binden; der neue Prozess startet halb, die CLI zeigt nur not ready.
Zu wenig RAM/Swap, OOM: auf kleinem VPS mit Modellpull plus Gateway kann der Node-Prozess vor Ready getötet werden—oft Exit 137 oder stilles Verschwinden.
Start-Timeout zu kurz: kalte Pulls oder Native-Builds überschreiten das Standard-startupTimeout, Healthchecks fallen früh durch, „ewig not ready“.
Falsches Log: bei gemischtem systemd/Docker-Debug tailt man den Container, während die Host-Unit noch eine alte Binary startet—oder umgekehrt.
Named-Volume-Rechte und UID-Mapping: der Container-User kann nicht schreiben; der Gateway restart-loop, außen nur not ready.
Image-Digest vs. Config-Drift: Compose zeigt auf :latest, aber Cache-Schichten passen nicht zu neuen openclaw.json-Feldern, Entry-Skript endet früh.
Netzwerk als Startfehler fehlinterpretiert: Timeouts beim Modell- oder Plugin-Registry hängen in Init—DNS/Egress vom Gateway trennen.
Gemeinsam: kein bedienbarer Zustand, daher wirkt status/RPC „halb grün“. Ins Ticket-Template, dann mit der Tabelle unten die Logfläche wählen und zwischen journal und docker logs nicht hin- und herspringen.
Passend zu Cross-Platform-Installation: dort „es installiert sich“; hier „es kommt nicht hoch“. Zu Observability: dort Langzeitmetriken und Rollback; hier harte Ausfälle vor erster Bereitschaft.
Läuft der Gateway auf einem dedizierten Remote-Mac oder kleinem Linux-VPS, gehören Mindest-RAM und Plattenpuffer ins Change-Review, nicht nur Versionspins—sonst not ready kurz vor Demos. Die Tabelle verdichtet „welches Log?“ zu einer Entscheidung.
Den Gateway nicht vor geklärtem Listen temporär ins öffentliche Internet hängen, um „Konnektivität zu testen“; Minimalfläche wie in Security-Hardening.
Bei not ready zuerst Einstiegsform: startet systemd den Prozess oder Compose im Container? Vermischen kostet Zeit.
| Dimension | Linux/macOS Bare Metal + systemd (oder launchd) | Docker / Compose |
|---|---|---|
| Erstes Logbild | journalctl -u <unit> -n 200 --no-pager oder Plattform-Äquivalent | docker compose logs --tail=200 <service>, an Restart-Zeitstempel ausrichten |
| Portkonflikte | Host: lsof -nP -iTCP:<port> -sTCP:LISTEN (Beispiel) | Lauscher auf Host und im Container; published Ports vs. bestehende Host-Dienste |
| Rechte / Volumes | Statusverzeichnis-Besitzer vs. Laufzeituser | Named-Volume-UID, read-only root vs. schreibbare Mounts; siehe Docker-Produktion |
| Timeouts / Retries | Unit TimeoutStartSec, Restart= | Healthcheck start_period, retries, Kaltstartzeit des Images |
| Upgrade / Rollback | Paketversion + Pfad letzter guter Config-Backup | festgelegter Image-Digest + versionierte Compose-Dateien; wie Observability-Rollback |
„Zuerst Listen verifizieren, dann Sessions“: in der not-ready-Phase lohnt sich Ports + Ressourcen + richtiges Logfenster, nicht zuerst Token ändern.
Bei Ubuntu 24.04 + systemd + Tunnel auch prüfen, ob das Tunnel-Upstream noch auf den aktuellen Port zeigt; sonst von außen dauernd not ready, lokal curl 127.0.0.1 ok.
In Docker oft falsch gelesen: „Container Exited, Compose wirkt stuck“—docker compose ps -a für Exit-Codes, dann Volumenrechte und Entry-Skript.
Lauscht der Prozess und Probes sind grün, Clients trotzdem kaputt: Session-Pfad in closed (1000).
Die Reihenfolge stellt günstige Checks vorn: Ressourcen und Ports vor Config und Images. Exakte Unterbefehle hängen von Ihrer OpenClaw-Version ab.
Parallele Retries einfrieren: Auto-Reconnect-Skripte pausieren, damit kein Sturm die Analyse überdeckt.
Version und Ressourcen-Snapshot: openclaw --version, uname -a, freier RAM/Platte ins Ticket.
Ports und alte Prozesse: Listen-Check auf dem konfigurierten Port; alte PID per systemd/Docker-Doku geordnet stoppen und neu starten.
doctor / validate: openclaw doctor oder Äquivalent, Lücken schließen, dann erneut starten.
Beobachtungsfenster verlängern: falls unterstützt, temporär gateway.startupTimeout oder Compose-Healthcheck-start_period erhöhen—„langsam“ vs. „tot“.
Mindestabnahme: wenn lokaler curl-Health oder offizieller Status „ready“ meldet, andere Nutzer wieder freigeben; sonst Eskalation mit Logs aus Abschnitt 4.
openclaw --version openclaw doctor # systemd-Beispiel: # journalctl -u openclaw-gateway -n 120 --no-pager # Docker-Beispiel: # docker compose logs --tail=120 gateway # danach Unit/Compose-Service laut Doku neu starten
Hinweis: bei Modell- oder Plugin-Download-Timeouts Egress vom Gateway trennen; im Wartungsfenster Allowlists kurz lockern, danach wieder straffen—Security-Hardening.
Zu Installationsüberblick: nach Wechsel von Anthropic-Abrechnung oder API-Key-Form Env und Config aus einer Quelle, sonst blockiert der Parser und wirkt wie not ready.
Auf einem dedizierten Remote-Mac mit Dauer-Gateway launchd/Unit-Restart und Plattenbereinigung ins gleiche Runbook, damit volle Platten keine not-ready-Schleife erzeugen.
Diese „Klartext → Aktion“-Karte im On-Call-Channel pinnen. Bei WebSocket-Close-Codes zu closed (1000) wechseln.
Port belegt: alten Prozess stoppen, dann neu starten; nicht ohne freien Port skalieren. Speicher knapp: Parallelität senken oder Swap/Upgrade, dann Tuning. Image-Pull fehlgeschlagen: zuerst docker pull oder Registry-Zugang, dann Gateway-Config.
Achtung: kein docker system prune in Produktion ohne Nachvollziehbarkeit; Named-Volume-Backups können weg sein. Aufräumwege ins Change schreiben.
Mit Observability: nach Fix Root-Cause-Label (Port/Speicher/Image/Volumen) setzen, damit die Klasse nicht wöchentlich neu aufgeht.
Läuft der Gateway mit MCP-Kindprozessen auf demselben Host, Startup auch Kind-Binärpfade und Sandbox-Mounts im Container prüfen—sonst blockiert das Parent beim Tool-Discovery.
Diese Felder für teamübergreifende Abstimmung; extern vorher anonymisieren.
Nur auf einem Notebook ist der Gateway an Schlaf und OS-Updates verwundbar; kleiner VPS OOMt oft beim Kaltstart. Für eine lang laufende, vertraglich saubere macOS-Ausführungsebene mit OpenClaw-Toolchain ist ein dedizierter Remote-Mac meist stabiler als Leihhardware. Gegen Flickenteppich liefert NodeMini Mac-Mini-Cloud-Miete festes SSH und klare Plattenstufen, damit „Gateway + Toolchain“ wie ein Estate-Knoten übergeben werden kann. Spezifikationen und Preise: Mac-Mini-Mietpreise; Onboarding: Hilfezentrum; OpenClaw-Serie über die Blog-Kategorie.
Dieser Artikel, wenn nicht gelauscht wird oder Ports/Speicher/Timeouts vermutet werden; closed (1000), wenn WebSocket stand und Policy/Session schloss. Kapazität und Onboarding: Mac-Mini-Mietpreise und Hilfezentrum.
docker compose logs --tail=120 gateway plus Host-dmesg/Ressourcen-Snapshot im gleichen Zeitfenster; bei Volumenverdacht docker compose ps -a-Exit-Codes anhängen.
Blog-Kategorie OpenClaw für Installation, Docker, systemd, Security, Observability und MCP; dieser Text für die Phase „startet nicht“.