jballment opened a new issue, #9168: URL: https://github.com/apache/hop/issues/9168
### What would you like to happen? **Feature request** When running Hop in Docker/CLI mode, process termination via OS signals should gracefully stop the currently running workflow/pipeline before JVM exit, using the same stop semantics already used by the GUI. **Problem** Today, GUI users can stop running executions through existing engine APIs (pipeline.stopAll() / workflow.stopExecution()), but headless executions (hop-run, including Docker entrypoint flows) may exit on signal without reliably invoking the same graceful stop path. This can lead to abrupt termination behavior and inconsistent shutdown semantics between GUI and CLI/container use. **Signals in scope** - Graceful path expected: SIGTERM, SIGINT, SIGQUIT, SIGHUP - Non-interceptable: SIGKILL (cannot be handled in shell/JVM; immediate termination is expected) **Use case: OpenShift disruptions / job interruption** In OpenShift, jobs and pods can be terminated during node drain, eviction, rolling updates, preemption, or disruption events. In these cases, containers typically receive SIGTERM and are given a limited termination grace period before force-kill. hop-run should use that SIGTERM window to request a graceful stop of active pipeline/workflow execution (same as GUI Stop), so running work can wind down cleanly instead of being abruptly cut off. **Why this matters** - Consistent stop behavior across GUI and non-GUI runtimes - Better shutdown reliability for orchestrated/container workloads (Kubernetes/OpenShift) - Reduced risk of partial cleanup or missed finalization on normal termination events **Suggested solution (minimal and safe)** - Add a JVM shutdown hook in HopRun that requests stop on the active execution using existing APIs: 1. pipelines: stopAll() 2. workflows: stopExecution() - Track active engine instance(s) in HopRunBase during run and clear them safely in finally. - Ensure the shutdown routine is idempotent (avoid duplicate stop calls/races during normal completion vs hook execution). - Keep relying on existing signal delivery path from container scripts to JVM: 1. docker/resources/run.sh 2. docker/resources/load-and-execute.sh - No new stop semantics required; reuse the proven GUI stop behavior. **Implementation notes (suggested files)** - engine/src/main/java/org/apache/hop/run/HopRun.java - engine/src/main/java/org/apache/hop/run/HopRunBase.java - (verify signal propagation only) docker/resources/run.sh, docker/resources/load-and-execute.sh **Acceptance criteria** - On SIGTERM/SIGINT/SIGQUIT/SIGHUP, running hop-run requests stop via existing engine stop APIs before process exit. - During OpenShift/Kubernetes disruption-driven termination, graceful stop is attempted within the pod grace period. - CLI/container stop behavior is consistent with GUI stop semantics. - Normal completion path remains unchanged. - SIGKILL behavior is documented as non-graceful/untrappable. ### Issue Priority Priority: 3 ### Issue Component Component: Hop Run -- 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]
