Further tracing of the system calls uWSGI makes leading up to our failures, looks like we get as far as:
http.c:450 calls http_parse(wsgi_req, ptr) after the request headers are built, the container returns a 500 error. See trace <https://gist.github.com/bdina/dbf5f270ec9c54c7ba30af2cfa318b0f>. -B On Thu, Apr 20, 2017 at 10:15 AM, Bryan Dina <[email protected]> wrote: > As part of this investigation yesterday I added some additional logging to > uWSGI (in plugins/python/python_plugin.c, plugins/python/pyloader.c, and > core/utils.c) to trace the execution flow in the app server, trying to > understand what it's doing when it tries to reload the application (which > is my REST API). > > On each request, uWSGI takes in the request and attempts to route it to > the appropriate application handler in the uwsgi_request_wsgi function. > This function calls the uwsgi_get_app_id function to return the id to route > the request call to, but this call returns -1. That call returns -1 because > an application name is defined but there is an app count of 0. Back > in uwsgi_request_wsgi, it would next attempt to route to the default > application, but it too has a -1 id value. > > I see that when the "no python application found" log message is produced, > internally when the uWSGI code attempts to find the app id there are no > applications found - which makes sense. The next question though still to > answer is why would this be? I want to understand how uWSGI initializes the > apps and further what events trigger said initialization. > > If there are other places or things I could do to instrument the code for > debugging with your advice I will go ahead and make those changes, build > the debug version of the uWSGI code and deploy. > > > -B > > On Wed, Apr 19, 2017 at 9:58 AM, Bryan Dina <[email protected]> wrote: > >> I am not aware of anything in my environment that would cause my >> application reload, is this something that uWSGI does as part of its normal >> lifecycle? I guess the question would be what causes reloads of an >> application in uWSGI. I am controlling uWSGI using supervisord, so I'm >> going to look through its configuration and documentation as well to figure >> out whether that could be the cause of a reload/restart of uWSGI. >> >> Below is a link to my uWSGI configuration and for completeness, I also >> included the supervisord configuration, >> >> https://gist.github.com/bdina/df6deeeb6abb95b1aad775b2b5c8d406 >> >> I will note that my configuration does have `autorestart=true` set. >> >> >> -B >> >> On Wed, Apr 19, 2017 at 1:28 AM, Roberto De Ioris <[email protected]> >> wrote: >> >>> >>> > I'm recently having problems with a python flask application running on >>> > uWSGI v2.0.12. This service is a REST API. What brought my attention to >>> > uWSGI is when the API periodically would return 500 Internal Server >>> error >>> > responses for calls that should always return 200 success. Even >>> requests >>> > that happen on a frequent basis fail some of the time but not all of >>> the >>> > time. It does not seem to have anything to do with the request itself >>> > (i.e. >>> > the data in the request is correct). >>> > >>> > Digging through the logs I noticed that each time a 500 response would >>> > happen, a log would be written with the text "no python application >>> > found". >>> > I then started looking for where this string would be coming from, and >>> > found it in the uWSGI native code. >>> > >>> > At this point I am trying to understand what could be the origin of >>> this >>> > error. I notice that the string would only ever get logged when the >>> > application id is found to be -1. What is not clear to me right now >>> though >>> > is what would cause that to happen? >>> > >>> > I can provide whatever information you need that I have not included in >>> > this message in a reply. >>> > >>> > >>> > >>> >>> Please post your configuration, but i would search better in uWSGI logs, >>> it could happen if your workers are not able to correctly reload the >>> application >>> >>> -- >>> Roberto De Ioris >>> http://unbit.com >>> _______________________________________________ >>> uWSGI mailing list >>> [email protected] >>> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >>> >> >> >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
