How about this flows?

1. Propagate SIGINT or SIGTERM signals directly to the currently running command.
2. Allow the command to complete its process.
3. If the command finishes, the taskfile should stop without triggering any further commands.

What do you think of this idea?

+1 Same here - the described problem prevents Docker from achieving a 'graceful exit'.
Any solutions?

I'm also experiencing this issue with Docker. My work around is to start the container with -d and then I have a stop task which I run at the beginning of the stop task to try and kill the container. It's fine, but it would be better if signals propagated.

Here's what I do for anyone who is dealing with this for Docker:

# https://taskfile.dev

version: "3"

vars:
  IMAGE_NAME: my-app
  IMAGE_TAG: latest
  IMAGE: "{{.IMAGE_NAME}}:{{.IMAGE_TAG}}"

tasks:
  default:
    desc: Shows this help message
    cmds:
      - task --list-all

  build:
    desc: Build the app
    cmds:
      - docker build . -t {{.IMAGE}}

  start:
    desc: Start the app
    deps:
      - build
    cmds:
      - cmd: task stop
        ignore_error: true
      - docker run -d --rm -p 8080:8080 --name my-app {{.IMAGE}}
      - cmd: docker logs --follow my-app
        ignore_error: true

  stop:
    desc: Stop the app
    cmds:
      - docker stop my-app

The signal handling is consuming these signals. You could try an experiment and comment out this line and see if it works like you expect.

Or, an alternative might be to send a different signal and see if that gets propagated. For instance, HUP as follows:

docker kill --signal=SIGHUP  task_container

and then you need a program that catches that ... basic idea here https://gobyexample.com/signals.

The actual process that Task runs seems to come into existence here and AFAICS nothing would prevent a signal propagating through (other than they are currently consumed by Task implementation).

I tried it without the signal.Notify(ch, ... line, didn't work.
Host: Arch linux x64
Image based on Alpine/Debian

Does it (Task) forward any signals to your test script? I wonder if any signals are propagated to the running shell.

Possibly its achieved by cancelling the context of the shell:
https://github.com/mvdan/sh/blob/5919e5ab226bf67b7a98b4925012cbd0a14d1096/interp/handler.go#L86

But it would take a bit more searching to figure out; if the signals are being propagated at all, and if not, could that effect be achieved.

I think I found it out... There's a third signal that should be added for task's signal.Notify: syscall.SIGURG. I was able to overcome the issue with local code like:

signalC := make(chan os.Signal, 1)
signal.Notify(signalC, os.Interrupt, syscall.SIGTERM, syscall.SIGURG)
go func() {
	var s os.Signal
	for {
		s = <-signalC
		if s != syscall.SIGURG {
			break
		}
	}
	log.Println("signal received", s)
	// graceful shutdown...
}

Here's my demo: https://github.com/vendelin8/go-task-docker-signal

Did you change anything in Task.

As I read through the code, it seems like InterceptInterruptSignals() is delaying task from shutting down (by consuming the signal delivered to task a few times before exiting). So you implemented that part differently?

#1924