Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kill container on app start fail #61

Closed
MiaMish opened this issue Jun 3, 2019 · 4 comments
Closed

Kill container on app start fail #61

MiaMish opened this issue Jun 3, 2019 · 4 comments
Labels

Comments

@MiaMish
Copy link

MiaMish commented Jun 3, 2019

I read this issue: tiangolo/uwsgi-nginx-flask-docker#3
It seems that setting need-app = true is not enough to kill the container, as supervisor keeps on restarting the app.
Please consider adding autoresetart=false in supervisord.conf section for uwsgi, or to make these easily configurable in other some way.
To have supervisor actually kill the container you'd have to set up some more configuration, see:
https://serverfault.com/questions/760726/how-to-exit-all-supervisor-processes-if-one-exited-with-0-result

@desaintmartin
Copy link
Contributor

If you are using an orchestrator like Kubernetes, you can add some liveness probe that will restart the container if either nginx or uwsgi is not working.

In any case, you can override the supervisor configuration file in your image to fit your needs!

I've been myself thinking of an even more extreme solution for some time now: have a dedicated nginx container and a dedicated uwsgi container. This way, it is atomic. But I haven't done it because... this image simply works for our use case and is easily debuggable.

@ReallyLiri
Copy link

Made the simple required steps to make image crash on app fail:
https://gist.github.com/ReallyLiri/f833510d350b242ff89b9b76fdf21ea5

@tiangolo
Copy link
Owner

Thanks for the discussion everyone! And thanks for the example @ReallyLiri.

I implemented it here: #110

The only caveat is that currently, Supervisor terminates "cleanly", with a 0 return code. I imagine it would be ideal for it to terminate with a non-zero return code, but it doesn't seem to be supported by Supervisor. I imagine it could be possible to "hack" around and make something (like the event handler maybe?) exit with some unexpected result, to make Supervisor take it as an error and exit with an error code. But that seems quite hacky, and probably not trivial to implement.

But for this specific issue, I hope that PR and the latest version of the image would handle it.

@github-actions
Copy link

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants