重启
有三种重启——先用哪一个
有两个同名的restart.sh，另外还有一个仅重新启动应用的方式。
“只需 6 秒的 Tomcat”这种说法不符合任何情况。
| 内容 | 位置 | 对象 | 耗时 |
|---|---|---|---|
| 主机重启 | plantpulse-edge-docker/bin/restart.sh | 整个容器——清理残留后重新启动 | 分钟级 |
| 堆栈重启 | $PE_HOME/bin/restart.sh | 网关所有模块——stop.sh + start.sh 作为一个进程运行 | 约 150–210 秒 |
| 仅应用重启 | $PE_HOME/bin/restart-app.sh | 仅 Tomcat（应用）。Cassandra · HiveMQ · Node-RED 保持不变 | 30–90 秒 |
大多数配置更改仅应用重启就足够了。只有需要重新启动 DB · MQTT · Node-RED 的场景（例如：mqtt.enable 切换）才需要堆栈重启。
仅应用重启（restart-app.sh）
屏幕上的应用重启按钮和 POST /api/v1/system/restart 会在 3 秒后触发此操作。
也可以直接执行。
$PE_HOME/bin/restart-app.sh
# 30~90초 후
curl -s http://127.0.0.1/api/v1/edge | jq
脚本会先检测 Cassandra（9042） · Redis（6379） · MQTT（1883），如果已停止运行，则会发出警告。因为即使仅重启应用，引导过程也必然失败（已知限制）。
为避免在“重启后无法恢复”上浪费时间，请先阅读该警告——在这种情况下，需要执行堆栈重启或先恢复该组件。
容器的 PID 1 监视器会在 Tomcat 进程消失时终止整个容器。 仅重启应用会使 Tomcat 在 30~90 秒内消失，因此会触发该监视。
因此，restart-app.sh 在启动时会创建 server/logs/.restart-in-progress 标记，
以告知“这是预期中的重启，请等待”，并在结束后删除它。此脚本在 Tomcat 进程树之外（setsid）运行，
因此即使在停止 Tomcat 时，它自身仍能存活并清除标记。
堆栈重启（$PE_HOME/bin/restart.sh）
在同一进程内依次运行 stop.sh 和 start.sh。
通过 ssh "stop.sh; start.sh" 远程执行时，如果仅断开 SSH 会话，可能会发生两种情况——
要么被遗弃在停止状态（start 无法开始），要么另一侧运行较晚的进程将已启动的堆栈再次停止。
因此，无论 stop 的结果如何，此脚本必须继续执行 start（保持停止状态是最糟糕的情况），并将结果写入标记文件，以便调用方确认完成。
远程调用方式如下。
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 의 종료 코드)
启动时逐个模块启动，并限制每个模块最多 300 秒 （防止某个模块无限等待导致整个引导过程停滞）。最后会检查最长 180 秒是否存活。
主机重启（plantpulse-edge-docker/bin/restart.sh）
安全地重启网关。与systemctl restart不同之处在于它会先清除残留的垃圾数据。
sudo /opt/kopens/plantpulse-edge-docker/bin/restart.sh
systemctl restart，可能因名称冲突而失败如果旧容器仍持有名称或存在僵尸进程，新容器将无法以 name already in use 启动。restart.sh 会先清理这些残留物，然后启动服务。
何时重启
| 情况 | 重启是否是答案 |
|---|---|
已更改配置（app.properties · 环境变量） | 是——配置在启动时读取一次 |
| 已更改驱动选项 | 否——按连接停止并重新启动即可 |
| 看起来采集停止 | 首先诊断和巡检——不了解原因就重启会丢失证据 |
| 已拉取新镜像 | 不是重启，而是升级 |
确认
cd /opt/kopens/plantpulse-edge-docker/bin
./status.sh
./health.sh
./logs.sh -f # 부팅을 따라가며 본다