[UPDATE]: add a minimal reproducible example

[codespearhead]

Add a MRE of the problem mentioned in the very first bullet-point of section "Why you need an init system", which can be solved by using dumb-init in the Dockerfile

[codespearhead]

@asottile I updated the previous message for clarity's sake.

[polarathene]

Your minimal example is not really minimal?

Here you go (no need for NodeJS, that JS is effectively just doing sleep, but with a visual countdown):

# CTRL+C will not stop the process exiting the container:
docker run --rm alpine sleep 30

# CTRL+C will now stop the container immediately (`--init` uses built-in `tini`):
docker run --rm -init alpine sleep 30

• The command sleep is PID 1, and PID 1 does not setup default signal handlers, so if your process does not take care of that it'll ignore the signal SIGINT sent via CTRL+C. If you want to immediately exit CTRL+\ will send SIGQUIT which is more akin to SIGKILL, but will often output a core dump with it.
• Likewise, if your PID 1 runs a child process, it'll not forward signals received by default (for a shell script you can use exec command-here, which will make the new command PID 1).
  • However within a container, when PID 1 exits, the container does so it'll bring down any child processes with it. dumb-init defaults to forwarding to an entire process group (if the README example with sleep is not helpful, you can see another comparison demonstrated here).
  • If you don't forward signals, those child processes cannot handle them for a graceful shutdown for example. PID 1 may only receive them and not do anything actionable or desired as a result.

This is just a signal handling example, not handling zombie processes.