stack exec not propagating signals when using Docker

[nh2]

This is exactly the same issue as #527, but when you have a stack.yaml that is Docker-enabled:

docker:
  enable: true

I falsely assumed that #527 was also about the Docker case, so please refer to #527 (comment) for a description of the problem.

This is the Docker issue that I believe would resolve this problem automatically if implemented: moby/moby#7567

[borsboom]

Not holding my breath on the upstream Docker issue getting fixed. Solution is probably to have stack catch signals and then proxy those itself using docker kill -s <signal>, at least for sigTERM and maybe some others.

[borsboom]

I've improved this significantly, and it at least works for sigTERM now. The container's current PID 1 (phusion/baseimage's my_init) doesn't pass other signals along to subprocesses, so I also have a workaround that, in non-interactive contexts, proxies a sigINT received by stack to a sigTERM for the container (this makes stopping a Bamboo/Jenkins task work properly, but keeps Ctrl-C working normally for other cases).

To fully fix this, we'd need a different PID 1. One approach would be to have stack itself act as PID 1, and have it pass along signals to its subprocesses, as well as reap zombie processes.

@nh2 Can you try the current master out for your use case?

[borsboom]

Blocked by #531.

[borsboom]

• A solution to this must handle the Ctrl-C in GHCI case mentioned in Ctrl-C kills stack ghci when Docker is used #1163.

[borsboom]

I've improved the signal handling significantly, but I don't think perfection is possible (I now understand why the Docker team decided to punt on this entirely for the interactive containers). More signals are now proxied, sigINT handling is more consistent, and sigTERM and sigABRT now give the container 30 seconds to exit gracefully before terminating it forcefully. Many signals don't make sense to proxy, and process control (STOP/CONT/etc.) doesn't work anyway (since there's usually no shell in the container to manage them, and if there is a shell it takes care of them on its own anyway), so these are not proxied. We can improve handling for signals on a case-by-case basis if a need can be demonstrated and there's a way to improve it without degrading other cases.