Ability to specify kill signal on step definition

[fishnux]

Hi,

In a DAG step, I'm running an app that supports graceful shutdown upon CTRL+C. I experimented stopping the DAG in the middle of execution, but it seems it's not the same thing as doing CTRL+C.

As a feature request, can we define the TERM signal in the step definition when an exit is requested? So, for this specific step, I can use SIGINT (CTRL+C)

Thanks 🙂

Edit: Meanwhile, I edited the source-code of the app to trap SIGTERM as well

[yottahmd]

Thanks for the feature request! :)

Currently if a signal is sent to a dagu process, it will forward the same signal to the running steps' process. So creating another DAG like below may be a workaround for now.

example:

schedule: "0 18 * * *" # schedule to stop the main DAG
steps:
  - name: stop the DAG
    command: pkill -INT -f "dagu start <DAG name>"

I was thinking about alternative solutions (more generic ones) to deal with the situation.

• Add --signal=<signal name> option to stop command (ex: dagu stop --signal=2 some_app.yaml)
• Add signalOnStop field to step field
• Add some handler function that enables to do something before the signal is forwarded by dagu

I think the first one is the one we can add easily for now, if it fits your situation. How do you think?

[fishnux]

Hi,

I use the UI to stop the DAG. The signalOnStop field to the step field would make more sense in this scenario I think. If this field is not specified then fallback to --signal or the signal passed to dagu stop

As for adding just the --signal without signalOnStopfield, at the moment I personally don't need it, thanks! :)

[yottahmd]

I see :) Then adding signalOnStop as a field of Step sounds good to me.

example:

steps:
  step:
    - name: step 1
      command: app.py
      signalOnStop: "SIGINT"

[yottahmd]

@fishnux This feature is implemented in v1.7.7. Thank you!