lizard restart

Rolling-Restart des aktuellen Builds — kein Rebuild.

Verwendung

lizard restart [nameOrId] [flags]

Flags

Flag	Beschreibung
`-s, --service <name>`	Dienst
`--detach`	Nach Annahme des Restarts zurückkehren
`--wait`	Warten, bis der neue Restart-Versuch bereit ist; funktioniert mit `--json`
`--timeout <seconds>`	Wartebudget für Bereitschaft mit `--wait`; Standard `120`
`--json`	JSON für Skripte zurückgeben

Beispiele

Einen Dienst neu starten

lizard restart --service api

Neustart ohne Streaming-Logs

lizard restart --service api --detach

Vor der nächsten Prüfung warten

Erfordert CLI 0.3.94 oder neuer. Verwende 0.3.95 oder neuer für Worker ohne HTTP.

lizard --json restart --service api --wait --timeout 120

Ohne --wait gibt der JSON-Modus nach Annahme des Restarts zurück. Mit --wait enthält das Ergebnis ok, status, attemptId und waitedMs. Die CLI wartet auf einen neuen Restart-Versuch, daher zählt ein unveränderter Status von vor der Anfrage nicht als Erfolg. Ein fehlgeschlagenes Warten oder ein Timeout liefert einen Exit-Code ungleich null zurück.

Bei HTTP-Diensten prüft die CLI zusätzlich die Dienst-Domain zweimal. Worker mit containerPort=0 verwenden den Bereitschaftsstatus aus dem Backend und benötigen keinen HTTP-Listener, selbst wenn sie eine generierte Domain haben.

lizard --json restart --service worker --wait --timeout 60

Das Timeout gilt für das Warten auf Bereitschaft nach der Restart-Anfrage. Es bricht den Restart nicht ab, und Netzwerkaufrufe können dazu führen, dass der gesamte Befehl länger dauert. Prüfe nach dem Befehl Anwendungsdaten oder einen Health-Endpunkt, wenn dein Workflow mehr als Prozessbereitschaft benötigt.

Siehe auch

lizard redeploy — einen frischen Build auslösen, statt den aktuellen wiederzuverwenden
lizard logs — Logs rund um einen Restart mit --restart latest oder --restart <id> prüfen
Bereitstellungen — Restarts vs. Redeploys und Wiederherstellung nach einem Absturz

redeploy service