IoTDB Edge: stop-edge.sh does not stop its own process when IOTDB_HOME is set, and reports success
- Lenguaje dominante
- Java
- Estrellas
- 6.4k
- Forks
- 1.2k
- Merge medio
- 1 d 23 h
- PR fusionados (30 d)
- 115
Descripción
### 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!
Guía de contribución
Línea de trabajo
Comienza con las líneas 23-24 de sbin/start-edge.sh y sbin/stop-edge.sh, especialmente con is_same_edge_home en las líneas 27-37, y después reproduce el caso de una instalación mediante symlinks con IOTDB_HOME establecido. Verifica que el proceso iniciado a través de la ruta del entorno se detenga, que el archivo PID se gestione correctamente y que la secuencia de detención/reinicio ya no deje al proceso antiguo atendiendo solicitudes.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- java, shell
- Área
- devops
- Tipo de issue
- Error
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Estado de actividad
- Activo
- Claridad
- Bien especificado
- Aptitud para principiantes
- 78/100