PDGGK opened a new issue, #18545: URL: https://github.com/apache/iotdb/issues/18545
### Search before asking - [X] I searched in the [issues](https://github.com/apache/iotdb/issues) and found nothing similar. ### Version master (`1106d85`, the merge of #18538). Not present in any release yet. ### Describe the bug and provide the minimal reproduce step `sbin/stop-edge.sh` can decline to stop its own Edge process, report success, and delete the PID file, leaving the process running. `start-edge.sh` honours an `IOTDB_HOME` taken from the environment: ```bash :23 if [ -z "${IOTDB_HOME}" ]; then :24 export IOTDB_HOME="$(cd "$(dirname "$0")"/.. && pwd)" ``` and passes that value to the JVM as `-DIOTDB_HOME=...`. `stop-edge.sh` recomputes it unconditionally from its own location: ```bash :23 IOTDB_HOME="$(cd "$(dirname "$0")"/.. && pwd)" ``` and `is_same_edge_home` (`:27-37`) matches the process command line against *that* string. When the two differ, the match fails. A versioned install behind a symlink is enough. With `$ROOT` standing in for the install parent, `$ROOT/iotdb` symlinked to `$ROOT/apache-iotdb-2.0.11-SNAPSHOT-edge-bin`: ``` process command line -DIOTDB_HOME=$ROOT/iotdb stop-edge.sh computes $ROOT/apache-iotdb-2.0.11-SNAPSHOT-edge-bin $ $ROOT/apache-iotdb-2.0.11-SNAPSHOT-edge-bin/sbin/stop-edge.sh Ignoring stale PID file $ROOT/apache-iotdb-2.0.11-SNAPSHOT-edge-bin/edge.pid; PID 63474 does not belong to this IoTDB Edge installation. No IoTDB Edge process from $ROOT/apache-iotdb-2.0.11-SNAPSHOT-edge-bin is running. $ echo $? 0 pid 63474 still running, 10710 and 6667 both still listening ``` Because `:96` has already removed the PID file, a second attempt prints only the last line, which is byte-identical to what the script prints when nothing was ever started. ### What did you expect to see? `stop-edge.sh` stops the Edge process started from the same installation, and a restart under a service manager picks up configuration changes. ### What did you see instead? A restart under a service manager reports success at both ends while nothing happens. Simulating `Environment=IOTDB_HOME=$ROOT/iotdb` with `ExecStart` and `ExecStop` given the real install path, and changing `dn_rpc_port` from 6667 to 6668 in between: ``` 1) ExecStart exit=0 pid 6669 up, 6667 listening 2) operator edits dn_rpc_port to 6668 3) ExecStop exit=0 pid 6669 still running 4) ExecStart exit=0 "The cn_internal_port 10710 is already occupied, PID: 6669" "Exit because there are occupied ports." 5) result the old process is still serving with the old configuration 6668 never listens, 6667 still does, edge.pid is now empty ``` `checkConfigNodePortUsages` also exits 0 when ports are occupied, so both halves of the restart look successful. The configuration change silently never takes effect and nothing is logged. ### Anything else? Four start/stop environment combinations, each from a fresh extraction of the packaged Edge archive. Every row was confirmed to have `10710` actually listening before the stop was issued: ``` start with IOTDB_HOME stop with IOTDB_HOME result ---------------------- --------------------- -------------------- symlink real path process still running symlink unset process still running unset symlink stopped unset unset stopped ``` ### Are you willing to submit a PR? - [X] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
