Hi Pavel, Most people use 'paste' for this :)
http://pypi.python.org/pypi/Paste <http://pypi.python.org/pypi/Paste>I've used this to catch uncaught exceptions before they have a chance to cause a 500, and it works great (for example, if django core libs fail to load). Cal On Thu, Apr 7, 2011 at 8:56 AM, Roberto De Ioris <[email protected]> wrote: > > > Roberto De Ioris <roberto@...> writes: > >> Hi, if you have not enabled --pep3333-input wsgi.input is a simple > >> socket, > >> so you do not have to read more than CONTENT_LENGTH bytes (so read() > >> will > >> block undefinetely). > >> > >> --pep3333-input instead will map wsgi.input to a custom object that > >> returns (in python3.x) bytes and allows read() and read(-1) without > >> blocking. > >> > > > > > > Thanks, updating to 0.9.7.2 and adding --pep3333 solved this particular > > issue, > > however my original point still stands: > > > > How can i get detailed information about 500 errors originating from > uWSGI > > in > > case if process is daemonized and there is nothing in the logs? > > > > > > This is something your app should do, if the python-side does not say what > is going wrong to uWSGI, it cannot print nothing in the logs. > > Start defining an action that simply raise an exception, this exception > should be caught by uWSGI. If not, something is wrong and we should > investigte further. > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > 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
