IoTDB Edge: stop-edge.sh does not stop its own process when IOTDB_HOME is set, and reports success

Inizia dalle righe 23-24 di sbin/start-edge.sh e sbin/stop-edge.sh, in particolare da is_same_edge_home alle righe 27-37, quindi riproduci il caso di un’installazione tramite symlink con IOTDB_HOME impostato. Verifica che il processo avviato tramite il percorso dell’ambiente venga arrestato, che il file PID venga gestito correttamente e che la sequenza di arresto/riavvio non lasci più il vecchio processo in servizio.

Search before asking

• I searched in the 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:

: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:

: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?

• I'm willing to submit a PR!