Interrupting Task Does Not Stop Execution of Subsequent Commands

[MoellerMarcel]

• Task version: v3.24.0 (h1:0DKsGTmqYbEaACffm9H2BOm8pTcuSnb5SRUl7TCilQ4=)
• Operating System: Windows Server 2022 Version 21H2
• Bash: GNU bash, version 5.2.12(1)-release (x86_64-pc-msys)

First of all, thanks for the great effort of building Task. I'm really looking forward to replacing my Makefiles with Taskfiles!

I ran across an unexpected behavior when interrupting a long-running script. Here's a minimal example:

With the Taskfile:

version: '3'

tasks:
  default:
    cmds:
      - echo "Hello "
      - sleep 5
      - echo "World"

If I interrupt (CTRL + C) the task during sleep, the second echo will still be executed. For example, I get the following output:

$ task
task: [default] echo "Hello "
Hello 
task: [default] sleep 5
task: Signal received: "interrupt"
task: [default] echo "World"
World

Switching from Make, I would expect the interrupt to stop the task (similar to how Task handles errors in commands).

For comparison, a Make script:

hello:
	echo "Hello "
	sleep 5
	echo "World"

will return:

$ make
echo "Hello "
Hello 
sleep 5
make: *** [Makefile:3: hello] Error 512

If this is the intended behavior, I suggest including it in the documentation. While searching for keywords like "interrupt," "kill," or "abort," I could not find anything related in the documentation.

[MoellerMarcel]

I did some digging and found that this behavior has been introduced with version 3.13.0, I guess by #769. So for anyone else running into the same problem, using version 3.12.1 works for me as of now.

[matzeeable]

Running into the same issue. We noticed that 32 GB of our RAM was full, and a look at the processes showed nicely that processes like webpack or tsc in watch mode were not closed. Unfortunately, downgrading is not a solution for us as we require some features introduced with newer versions.

EDIT: I found out that this happens only when closing the terminal or stopping the process with CTRL + Z. With CTRL + C taskfile correctly detects the interruption:

See also: What is the difference between Ctrl-z and Ctrl-c in the terminal?

[fedegiova]

Same problem at my side. I think that the issue is here:

task/signals.go

Line 28 in 4774273

os.Exit(1)

Calling os.exit without waiting for children to stop is an error in the unix world, they'll become zombies :D .

After the 3rd signal the code should propagate it to the child and then wait for them to terminate. Unfortunately I don't know enough go to help on that. But I can help on the unix part.

[kristiandrucker]

I'm having the same issue where I have a signal handler in my golang application which I'm running with watch and it only interrupts it when I press ctrl+c instead "on reload"

        sigs := make(chan os.Signal, 1)
	signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)
	go func() {
		sig := <-sigs
		log.Info("Received interrupt", "sig", sig)
		cancel()
	}()

[trulede]

Task currently monitors SIGINT SIGTERM and uses that as a debounce counter (3 times) before calling os.Exit(1). This is intended to give processes being run by task an opportunity to shutdown. All signals should be forwarded to the processes being run by task. There is no interception of signals by Task.

I will close this issue, as everything is working as expected; SIGHUP has no effect in Task, and SIGTSTP suspends Task and the processes it is running.

If this is still a problem, please open new issues with working example to demonstrate the problem. Use simple commands (sleep, signal, tail, echo) so that we can understand and experiment with the scenarios. Task repo includes a sleepit command which is also useful.

The watcher is notoriously difficult, however that is already covered by #160. I've opened #2642 for the request to support SIGHUP in the watcher.