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:
- Das root-
stop.shruft die$PE_HOME/<module>/bin/stop.shder einzelnen Komponenten der Reihe nach auf - Beendigung in der Reihenfolge Tomcat → Node-RED → MQTT → timeseries-engine → timeseries-dashboard → Redis → Cassandra
- Jedes Module-Stop versucht zunächst eine Graceful-Beendigung; wird der Prozess nicht innerhalb von
STOP_TIMEOUT_SECONDS=20beendet, wird nur die betroffene Komponentekill -9 - Das Cassandra-Module-Stop synchronisiert unmittelbar vor der Beendigung mit
nodetool flush+draindie 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.shbei 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.sh → start.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
| Symptom | Ursache / Abhilfe |
|---|---|
Schritt nodetool drain dauert sehr lange | Große Menge ungeflushter Daten im Speicher. Normalerweise im Minutenbereich — prüfen, ob die Disk-I/O frei ist |
KILL (timeout 20s) tritt jedes Mal auf | Einzelne Prozesse ignorieren SIGTERM. Normalerweise unkritisch, bei wiederholtem Auftreten jedoch das Log der Komponente prüfen |
Nach der Beendigung verbleiben Prozesse in ps.sh | Muster-/Port-Erkennung $PE_HOME/<module>/bin/stop.sh der betroffenen Komponente prüfen |
4. Verifizierung
$PE_HOME/bin/ps.sh
# 출력이 비어있어야 정상
5. Weiterführend
- Zum Wiederhochfahren: Start (
start.sh) - Einfacher Neustart: Neustart (
restart.sh) - OS-Reboot:
reboot.sh(einfacher OS-Reboot — Aufruf nachstop.shempfohlen)