apache / apache/iotdb

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

Open Beginner friendly
#18,545 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
6.4k
Forks
1.2k
Avg merge
1d 23h
Merged PRs (30d)
115

Description

### 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!

Contributor guide

Open the contributing guide

Research direction

Start with sbin/start-edge.sh lines 23-24 and sbin/stop-edge.sh, especially is_same_edge_home at lines 27-37, then reproduce the symlinked-install case with IOTDB_HOME set. Verify that the process started through the environment path is stopped, the PID file is handled correctly, and the stop/restart sequence no longer leaves the old process serving.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, shell
Domain
devops
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.