Restart
There are three types of restart — decide which one you need
Two of them go by the same name as restart.sh, and there's a third one that only restarts the app.
The phrase "Tomcat only takes 6 seconds" does not apply to any of them.
| What | Where | Target | Time required |
|---|---|---|---|
| Host restart | plantpulse-edge-docker/bin/restart.sh | Entire container — cleans up remnants and restarts | Minutes |
| Stack restart | $PE_HOME/bin/restart.sh | All gateway modules — stop.sh + start.sh as a single process | ~150–210 sec |
| App-only restart | $PE_HOME/bin/restart-app.sh | Tomcat only. Cassandra · HiveMQ · Node-RED remain unchanged | 30–90 sec |
Most configuration changes can be handled with app-only restart. Only tasks that require bringing up the DB · MQTT · Node-RED layers again (e.g., toggling mqtt.enable) need a stack restart.
App-only restart (restart-app.sh)
The Restart App button on the screen and POST /api/v1/system/restart call this after a 3-second delay.
You can also run it directly from the command line.
$PE_HOME/bin/restart-app.sh
# 30~90초 후
curl -s http://127.0.0.1/api/v1/edge | jq
The script first probes Cassandra (9042) · Redis (6379) · MQTT (1883); if any is down, it prints a warning. Bootstrap will fail even if you restart the app alone (known limitation).
Read that warning before spending time on "it doesn't come back after restart" — in that case, you need a stack restart or to revive the component first.
The container's PID 1 supervisor shuts down the entire container if the Tomcat process disappears. In an app-only restart, Tomcat is absent for 30–90 seconds, so the supervisor catches that.
Therefore, restart-app.sh creates a server/logs/.restart-in-progress marker at startup to signal "this is an intentional restart — wait for it," and removes it when finished. This script runs detached from the Tomcat tree (setsid), so it survives and clears the marker even as Tomcat is killed.
Stack restart ($PE_HOME/bin/restart.sh)
stop.sh and start.sh are executed within a single process sequentially.
When executed remotely via ssh "stop.sh; start.sh", if the SSH session is simply disconnected, one of two things happens:
the process is left frozen (start never runs), or the late-finishing counterpart kills an already-recovered stack again.
That's why this script always proceeds to start regardless of the stop result (leaving the stack down is the worst case), and writes the result to a marker file so the invoking side can confirm completion.
For remote invocation, use this:
ssh 박스 "RESTART_RUN_ID=xyz nohup setsid $PE_HOME/bin/restart.sh >/dev/null 2>&1 </dev/null &"
# 그다음 /tmp/pp-restart-xyz.done 을 폴링한다 (내용이 start.sh 의 종료 코드)
Startup brings modules up sequentially with a per-module maximum wait of 300 seconds (this prevents one module from blocking the entire boot indefinitely). At the end, it checks liveness for up to 180 seconds.
Host restart (plantpulse-edge-docker/bin/restart.sh)
Cleanly restarts the gateway. The difference from systemctl restart is that it first cleans up any leftover remnants.
sudo /opt/kopens/plantpulse-edge-docker/bin/restart.sh
systemctl restart can fail due to name conflictsIf an old container still holds the name, or there are zombie processes, the new container cannot start as name already in use. restart.sh cleans up those remnants first and then brings up the service.
When to restart
| Scenario | Is restart the answer? |
|---|---|
Changed configuration (app.properties · environment variables) | Yes — configuration is read once at startup |
| Changed driver options | No — stop and start the connection unit instead |
| Collection appears to be stalled | First check Diagnostics & Inspection — restarting without knowing the cause destroys the evidence |
| Pulled a new image | Not a restart — use Upgrade |
Verification
cd /opt/kopens/plantpulse-edge-docker/bin
./status.sh
./health.sh
./logs.sh -f # 부팅을 따라가며 본다