3 ms·
The most important thing I know about signals is that in dockerized applications, your ENTRYPOINT or CMD must use the exec form (`["command", "arg1", "arg2"]`)
by claytonjy 3y ago
The most important thing I know about signals is that in dockerized applications, your ENTRYPOINT or CMD must use the exec form (`["command", "arg1", "arg2"]`) in order for your application to receive signals.
A lot of applications, like web/API frameworks, will gracefully shutdown if they receive SIGTERM or SIGINT, but if that signal doesn't propagate to the app you'll need to SIGKILL instead. Kubernetes will do this for you, waiting for your process to shutdown and then ungracefully killing it when it doesn't do so in time.
But you can't do env var substitution with the exec form...
- corytheboyd 3y agoIsn’t this something that Tini solves? Really easy to add to compose services with “init: true”
- Spivak 3y agoIt really should be the default, I can't think of any containerized application that actually upholds the responsibilities of PID1.
- corytheboyd 3y agoYeah I don’t disagree at all. I’ve seen so many people just put up with waiting for their containers to get SIGKILLed by the docker timeout, when they could instead use tini to forward SIGINT to trigger their graceful shutdowns. Drives me nuts haha
- claytonjy 3y agoI think it's supposed to? I'm generally running on k8s with base images that don't include tini, so I've settled for exec-style CMD instead
- corytheboyd 3y agoAh gotcha. I believe it can be baked into images as well, per the entrypoint example in the readme: https://github.com/krallin/tini https://github.com/krallin/tini Not sure how this will fare IRL in k8s as I haven’t much experience there. It’s still silly that this is the default behavior where you need something like Tini, but I digress.
- nolist_policy 3y agoIt should work if you write "exec ...". This way the command replaces the shell, instead of becoming a child process of the shell.