Zum Hauptinhalt springen

Stoppen (stop.sh)

Legacy-Native-Seite

Diese Seite gilt ausschließlich für Native-Deployment-Boxen vor 2026.05. Boxen im Container-Modus (2026.05+) siehe systemctl stop plantpulse-edge.service — der SIGTERM-Trap des entrypoint ruft das interne stop.sh (inklusive Graceful Cassandra Drain) auf.

1. Verwendung

$PE_HOME/bin/stop.sh

Ablauf:

  1. Das root-stop.sh ruft die $PE_HOME/<module>/bin/stop.sh der einzelnen Komponenten der Reihe nach auf
  2. Beendigung in der Reihenfolge Tomcat → Node-RED → MQTT → timeseries-engine → timeseries-dashboard → Redis → Cassandra
  3. Jedes Module-Stop versucht zunächst eine Graceful-Beendigung; wird der Prozess nicht innerhalb von STOP_TIMEOUT_SECONDS=20 beendet, wird nur die betroffene Komponente kill -9
  4. Das Cassandra-Module-Stop synchronisiert unmittelbar vor der Beendigung mit nodetool flush + drain die Dirty-Daten aus dem Speicher auf die Festplatte

Normale Ausgabe:

PLANTPULSE EDGE STOP (module scripts, max 20s each) ...
SERVER STOP ... tomcat stopping ... KILL (timeout 20s)
FLOW TOOL STOP ... node-red stopping ... OK (3s)
MQTT STOP ... mqtt stopping ... OK (5s)
TIMESERIES ENGINE STOP ... timeseries-engine already stopped
TIMESERIES DASHBOARD STOP ... grafana stopping ... OK (0s)
CACHE STOP ... redis stopping ... KILL (timeout 20s)
DATABASE STOP ... cassandra stopping ... OK (1s)
STOP COMPLETED.

Dauer ca. 60–90 Sekunden.


2. Wann wird es aufgerufen

  • Unmittelbar vor einem Backup — damit backup.sh bei sauber geschlossenem Cassandra-Commitlog arbeitet.
  • Unmittelbar vor einem OS-Reboot — wird ohne Drain heruntergefahren, dauert die Commitlog-Wiederherstellung beim nächsten Start länger.
  • Reguläre Inspektion — wenn nach Logikänderungen/Patches ein sauberer Neustart gewünscht ist.
Nicht für einen einfachen Tomcat-Neustart verwenden

Jedes Mal stop.shstart.sh aufzurufen bedeutet 2–3 Minuten Ausfallzeit. Um nur Code/Konfiguration zu übernehmen, verwenden Sie restart.sh (nur Tomcat-Neustart, 6 Sekunden).


3. Häufige Stolperfallen

SymptomUrsache / Abhilfe
Schritt nodetool drain dauert sehr langeGroße Menge ungeflushter Daten im Speicher. Normalerweise im Minutenbereich — prüfen, ob die Disk-I/O frei ist
KILL (timeout 20s) tritt jedes Mal aufEinzelne Prozesse ignorieren SIGTERM. Normalerweise unkritisch, bei wiederholtem Auftreten jedoch das Log der Komponente prüfen
Nach der Beendigung verbleiben Prozesse in ps.shMuster-/Port-Erkennung $PE_HOME/<module>/bin/stop.sh der betroffenen Komponente prüfen

4. Verifizierung

$PE_HOME/bin/ps.sh
# 출력이 비어있어야 정상

5. Weiterführend