Checking signal handling in containers

signal_handle.sh

# Dockerfile run and has two formats... see https://docs.docker.com/engine/reference/builder/#run
RUN <command> # (shell form which by default is /bin/sh -c ...)
RUN ["executable", "param1", "param2"] # (exec form... not wrapped in a shell)

# Same for entrypoint https://docs.docker.com/engine/reference/builder/#entrypoint
ENTRYPOINT command param1 param2 # (shell form https://docs.docker.com/engine/reference/builder/#shell-form-entrypoint-example )
ENTRYPOINT ["executable", "param1", "param2"] # (exec form https://docs.docker.com/engine/reference/builder/#exec-form-entrypoint-example )

# and cmd https://docs.docker.com/engine/reference/builder/#cmd
CMD command param1 param2 # (shell form)
CMD ["executable","param1","param2"] # (exec form, this is the preferred form)
CMD ["param1","param2"] # (as default parameters to ENTRYPOINT)



# Also if your entry point is a shell script you can forward signals using: exec /bin/company/program
# But also be aware this may not work if bash is started with -c with multiple commands:

# Execve is used when passing single command. See https://man7.org/linux/man-pages/man2/execve.2.html
# Signals will be handled by command. 
/bin/bash -c 'sleep 200'
# Fork is used when passing multiple commands. See https://man7.org/linux/man-pages/man2/fork.2.html
# Signals to bash will not be handled by command.
/bin/bash -c 'echo foo; sleep 200'

Or for a Go based yaml/pod spec renderer, can use something like https://gist.github.com/alienth/e2e356c719f7a47b0af0dde829c4601d

Very interesting nuances. Thanks for the heads-up!