Stop (stop.sh)

Legacy native page

This page applies only to native deployment boxes prior to 2026.05. For boxes in container mode (2026.05+), see systemctl stop plantpulse-edge.service — the entrypoint's SIGTERM trap invokes the internal stop.sh (including a graceful Cassandra drain).

1. Usage

$PE_HOME/bin/stop.sh

Execution order:

1. The root stop.sh calls each component's $PE_HOME/<module>/bin/stop.sh in sequence
2. Shutdown proceeds in the order Tomcat → Node-RED → MQTT → timeseries-engine → timeseries-dashboard → Redis → Cassandra
3. Each module stop first attempts a graceful shutdown; if the process does not exit within STOP_TIMEOUT_SECONDS=20, only that component is kill -9
4. The Cassandra module stop runs nodetool flush + drain just before shutdown to sync dirty data in memory to disk

Normal output:

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.

Takes ~60–90 seconds.

---

2. When to run it

• Immediately before a backup — so that backup.sh runs with the Cassandra commitlog cleanly closed.
• Immediately before an OS reboot — shutting down without a drain makes commitlog replay take longer on the next boot.
• Scheduled inspection — when you want to bring the system back up in a clean state after logic changes or patches.

Do not use this for a simple Tomcat restart

Calling stop.sh → start.sh every time means 2–3 minutes of downtime. To apply code or configuration changes only, use restart.sh (restarts Tomcat only, 6 seconds).

---

3. Common pitfalls

Symptom	Cause / Resolution
The nodetool drain step takes too long	Large amount of unflushed data in memory. Usually on the order of minutes — verify that disk I/O is not saturated
KILL (timeout 20s) occurs every time	Some process is ignoring SIGTERM. Normally harmless, but if it happens every time, check that component's logs
Processes remain in ps.sh after shutdown	Check that component's $PE_HOME/<module>/bin/stop.sh pattern / port detection

---

4. Verification

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

---

5. Learn more

• To bring the system back up: Start (start.sh)
• Simple restart: Restart (restart.sh)
• OS reboot: reboot.sh (a plain OS reboot — recommended to run it after stop.sh)