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

Disable 'full dynamic mode' AKA 'no app loaded'? #1172

Open
adamhadani opened this issue Feb 2, 2016 · 4 comments

Comments

@adamhadani
Copy link

commented Feb 2, 2016

Hello,
I"ve noticed in certain cases when running a Flask app via uwsgi, uwsgi would start and remain running despite errors in underying app, giving away the familiar error:

unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***

with subsequent requests giving

--- no python application found, check your startup logs for errors ---

While the root cause is usually easy to debug, this sort of 'silent' error (whereby uwsgi keeps running, making supervisord think the application started and is running successfully) is very dangerous, and we would rather have it just fail outright.

So, TL;DR - How do I disable this 'full dynamic mode'? e.g just make it fail completely if underlying Python WSGI app errors?

@adamhadani

This comment has been minimized.

Copy link
Author

commented Feb 2, 2016

To answer myself: found my answer with '--need-app' (as described for example here: https://uwsgi-docs.readthedocs.org/en/latest/FallbackConfig.html)

This was not obvious and I think the default is dangerous for many environments, specifically having 'silent errors' whereby the uwsgi process would not crash even though it runs no app. So I suggest --need-app as a default option and supporting disabling it if a fallback or some --full-dynamic-mode flag are set

@mwarkentin

This comment has been minimized.

Copy link

commented Jun 1, 2017

This just bit us on a production deployment the other day - looks like uwsgi launched in "dynamic" mode after our Django settings failed to load because of an invalid variable reference. Because uwsgi was "up", our docker health check passed, and ECS was happy to cycle out our old functional containers.

+1 to this being the default functionality, was quite surprising to us.

@e-ruiz

This comment has been minimized.

Copy link

commented Jul 28, 2017

If there is no app, why on earth uwsgi goes up?
uWSGI 2.0.15

+1 to this being the default functionality, was quite surprising to me.

@unbit

This comment has been minimized.

Copy link
Owner

commented Jul 28, 2017

@e-ruiz because in 2008-2009 it was the only supported way to configure apps (the webserver instructed the application server about the app to load). If you try to go back to that time (where even the concept of proxying was not so widely approved) you will understand why it was a pretty obvious decision for a software aimed at shared hosting.

Now things have changed but there are still dozens of customers (paying customers) that use this kind of setup, and by default we do not change default unless after a looooong deprecation phase.

Having said that, last year we decided to fix all of the bad defaults (expecially for the python plugin) in the 2.1 branch. So feel free to make a pull request and i will merge it for sure as dynamic mode is basically the most 'legacy' feature of the project :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.