Hacker News new | past | comments | ask | show | jobs | submit login

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...




It should work if you write "exec ...". This way the command replaces the shell, instead of becoming a child process of the shell.


Isn’t this something that Tini solves? Really easy to add to compose services with “init: true”


It really should be the default, I can't think of any containerized application that actually upholds the responsibilities of PID1.


Yeah 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


I 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


Ah gotcha. I believe it can be baked into images as well, per the entrypoint example in the readme: 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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: