OpenClaw unter systemd: Einen zweiten Gateway-Supervisor vermeiden

Ein OpenClaw-Gateway läuft als systemweiter systemd-Dienst unter einem eigenen Servicekonto. Wer den Zustand prüft oder eine Wartung fährt, darf dabei keine zweite Unit im User-Scope anlegen. Genau hier entsteht der teure Irrtum: Ein gestoppter Dienst sieht aus wie ein fehlender Dienst, wenn nur im falschen Scope gesucht wird — und die naheliegende „Reparatur“ ist dann ausgerechnet die Ersatz-Unit, die den Schaden erst anrichtet.

Ein Gateway braucht genau einen Supervisor

Ist das Gateway als System-Unit eingerichtet, bleibt diese Unit die maßgebliche Dienstdefinition. Eine zusätzliche User-Unit für denselben Prozess schafft einen zweiten Supervisor, und beide konkurrieren im ungünstigsten Fall um Prozess, Port und Neustartlogik. Zwei Supervisoren sind einer zu viel.

Installierte Gateway-Units werden inzwischen in ihrem tatsächlichen User- oder System-Scope inspiziert. Der erkannte Manager wird durch Kommando- und Runtime-Prüfung durchgereicht, und die eigene Unit erscheint weder als zusätzlicher Dienst noch als Kandidat für eine Entfernung. Konkurrierende Supervisoren bleiben dagegen ausdrücklich sichtbar. Systemeigene Definitionen werden nicht umgeschrieben.

Der aussagekräftige Test ist der gestoppte Zustand. Wird die vorhandene System-Unit dann als fehlend behandelt oder taucht plötzlich eine zweite auf, stimmt die Zuordnung von Scope oder Dienstidentität nicht.

Erst Status lesen, dann Doctor starten

Das Gateway-Runbook von OpenClaw nennt als gesunde Basis Runtime: running, Connectivity probe: ok und eine Capability-Zeile, die den Erwartungen entspricht. Der Einstieg bleibt derselbe wie immer:

• openclaw gateway status für den Gateway-Dienst,
• openclaw status für den übergeordneten Zustand,
• openclaw logs --follow zum Eingrenzen von Start-, Verbindungs- oder Supervisor-Problemen.

openclaw gateway status --deep ergänzt laut Runbook einen systemweiten Service-Scan; es ist ausdrücklich keine tiefere RPC-Prüfung, sondern zusätzliche Dienstsuche. Für eine installierte System-Unit meldet dieser Pfad nach der aktualisierten Gateway-Dokumentation systemd system.

Bei einer Offline-Wartung darf der Dienst selbstverständlich gestoppt sein. Die Reihenfolge ist dann aber vorgegeben: Der Eigentümer der System-Unit stoppt das Gateway, anschließend läuft openclaw doctor --fix unter dem in User= eingetragenen Nicht-Root-Konto mit denselben State- und Config-Pfaden, und derselbe Service-Eigentümer startet die Unit danach wieder. So bleiben Dienstdefinition und Wartungsidentität deckungsgleich, ohne dass eine konkurrierende User-Unit entsteht.

Bei unklarer Zuständigkeit abbrechen

Kann die Zuständigkeit nicht verifiziert werden, ist das kein Anlass für eine Ersatz-Unit. Es ist ein Stoppsignal. Ein nicht erreichbarer Manager oder ein nicht verifiziertes Servicekonto blockiert die Wartung weiterhin — und das ist die richtige Voreinstellung, weil ein blockierter Doctor-Lauf billiger ist als ein zweiter Supervisor im Produktivbetrieb.

Prüfe in diesem Fall, welche Unit installiert ist, in welchem Scope sie liegt und welches Konto in User= steht. Erzwinge nichts unter einem anderen Account. Und wechsle erst recht nicht in den User-Scope, nur damit ein Befehl durchläuft.

Die Mindestregel lautet: eine Gateway-Instanz, eine Dienstdefinition, ein verantwortliches Servicekonto. Jede zusätzliche Supervisor-Ebene ist zunächst ein Fehlerbild, keine Reparatur.