Uwsgi: Disable 'full dynamic mode' AKA 'no app loaded'?

[adamhadani]

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]

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

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]

@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 :)