dolphinscheduler icon indicating copy to clipboard operation
dolphinscheduler copied to clipboard

[Feature][Task - kill task] Support user to config kill signal type of killing process/task

Open ws752499660 opened this issue 9 months ago • 3 comments

Search before asking

  • [x] I had searched in the issues and found no similar feature requirement.

Description

I noticed that if user try to kill the task/process, for example, a Java task, dophin scheduler will send "kill -9" which is "SIGKILL" signal to java worker process.

Would you please make the kill signal be configable? Becasue in some situation, we want worker process to send "I am killed" message to specific observer application or do something else to clean resource when user try to kill task/process via dophin scheduler. And if the worker process is killed by ""SIGKILL" signal, there is no chance for "JVM runtime hook" to do something when the process needed to exit.

Thererfore, would you please make the kill signal be configable? Thanks for your help.

Use case

User can be config the kill signal type of specific work process/task.

Related issues

No response

Are you willing to submit a PR?

  • [ ] Yes I am willing to submit a PR!

Code of Conduct

ws752499660 avatar Apr 03 '25 03:04 ws752499660

Hi @SbloodyS i am willing to take this feature

DhiyaneshwaranR avatar Apr 03 '25 08:04 DhiyaneshwaranR

Hi @SbloodyS i am willing to take this feature

I've assigned to you. Looking forward to your contribution.

SbloodyS avatar Apr 04 '25 03:04 SbloodyS

Hi @ws752499660

Thanks for raising this!

Just to clarify — starting from DolphinScheduler v3.3.0-alpha, the task kill logic has already been improved as part of PR #17005. It now follows a graceful shutdown sequence:

SIGINT → SIGTERM → SIGKILL

So: • If a task supports graceful termination (e.g., Java with shutdown hooks), it will now handle that properly via SIGINT. • SIGKILL is only used as a last resort if the earlier signals fail.

At the moment, configuring or customizing the kill signal (globally or per-task) is not available — it follows the fixed order above.

@SbloodyS would it still make sense to work on this as a configurable feature, or should we consider this already resolved since the graceful signal flow is now in place?

DhiyaneshwaranR avatar Apr 19 '25 22:04 DhiyaneshwaranR