ricky2129 opened a new pull request, #12710:
URL: https://github.com/apache/seatunnel/pull/12710
### Purpose of this pull request
When a SeaTunnel Engine node runs in the foreground (Docker, Kubernetes),
stopping it never reaches the JVM.
It is always SIGKILLed after the grace period.
- `seatunnel-cluster.sh` starts the JVM as a child process (`java ...`), not
with `exec java ...`.
- The Helm chart then wraps the script in `/bin/sh -c`, so the process tree
in the pod is:
```
PID 1 /bin/sh -c /opt/seatunnel/bin/seatunnel-cluster.sh -r master
PID 8 /bin/bash /opt/seatunnel/bin/seatunnel-cluster.sh -r master
PID 11 java ...
org.apache.seatunnel.core.starter.seatunnel.SeaTunnelServer
```
- Kubernetes and Docker send SIGTERM only to PID 1.
- `/bin/sh` installs no SIGTERM handler (`/proc/1/status`: `SigCgt:
0000000000010002`, i.e. SIGINT and SIGCHLD only). The kernel drops
unhandled signals for PID 1, so SIGTERM is ignored.
- The JVM never runs its shutdown hooks, and the container is SIGKILLed when
`terminationGracePeriodSeconds` expires.
As a result, every rolling update or pod deletion behaves like a crash:
- Hazelcast never leaves the cluster cleanly, so
`hazelcast.shutdownhook.policy` has no effect.
- Running jobs fail over from their last checkpoint instead of stopping
cleanly.
- Every pod takes the full grace period to terminate.
This PR:
1. `seatunnel-cluster.sh`: foreground mode uses `exec java ...`, so the JVM
replaces the shell and keeps its PID. Daemon mode (`-d`,
`nohup ... &`) is unchanged.
2. Helm chart: master and worker run the script directly instead of through
`/bin/sh -c`, so the JVM becomes PID 1. Both parts are
needed: with only (1), `/bin/sh -c` stays PID 1 and still drops the
signal.
### Does this PR introduce _any_ user-facing change?
Yes.
- Stopping a foreground SeaTunnel Engine node now delivers SIGTERM to the
JVM. Shutdown hooks run (Hazelcast honours
`hazelcast.shutdownhook.policy`), and the process exits with 143 within
seconds, instead of being SIGKILLed (137) after the
grace period.
- Users who override `master.command` / `worker.command` in the chart are
unaffected.
### How was this patch tested?
Manual A/B with the same image, stopping the container with `docker stop -t
30` (SIGTERM, then SIGKILL after 30s, same as a pod
delete):
| start command | PID 1 | stop took | exit code | shutdown hook |
|---|---|---|---|---|
| `/bin/sh -c "seatunnel-cluster.sh -r master"` (before) | `/bin/sh` | 30s |
137 (SIGKILL) | not run |
| `seatunnel-cluster.sh -r master` with `exec java` (after) | `java` | <1s |
143 (SIGTERM) | `Running shutdown hook... is SHUTTING_DOWN` |
The "before" process tree and signal mask above come from a production
Kubernetes deployment of the chart.
### Check list
* [ ] If any new Jar binary package adding in your PR, please add License
Notice according
[New License
Guide](https://github.com/apache/seatunnel/blob/dev/docs/en/contribution/new-license.md)
* [ ] If necessary, please update the documentation to describe the new
feature. https://github.com/apache/seatunnel/tree/dev/docs
* [ ] If necessary, please update `incompatible-changes.md` to describe the
incompatibility caused by this PR.
* [ ] If you are contributing the connector code, please check that the
following files are updated:
1. Update
[plugin-mapping.properties](https://github.com/apache/seatunnel/blob/dev/plugin-mapping.properties)
and add new connector information in it
2. Update the pom file of
[seatunnel-dist](https://github.com/apache/seatunnel/blob/dev/seatunnel-dist/pom.xml)
3. Add ci label in
[label-scope-conf](https://github.com/apache/seatunnel/blob/dev/.github/workflows/labeler/label-scope-conf.yml)
4. Add e2e testcase in
[seatunnel-e2e](https://github.com/apache/seatunnel/tree/dev/seatunnel-e2e/seatunnel-connector-v2-e2e/)
5. Update connector
[plugin_config](https://github.com/apache/seatunnel/blob/dev/config/plugin_config)
--
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]
