Re: Apache WSGI woes

In message <DM6PR08MB4778FEA089A9C31A4FA3C46ECAC30@DM6PR08MB4778.namprd08.prod.o
utlook.com>,
Tom Ekberg writes:
> Occasionally, I get an HTTP 500 error (Internal Server Error). I've
> tried restarting apache which doesn't help. I instrumented mod_wsgi to
> add more detail to the logs in 29 places where errors are detected
> thinking that might help isolate the problem. The log for this error is:
>
>[Wed Nov 14 21:24:52.014080 2018] [wsgi:error] [pid 19848] [remote 10.146.1=
>22.53:52967] mod_wsgi (pid=3D19848): Exception occurred processing TWE1 WSG=
>I script '/opt/roundup/trackers/demo/apache/demo_wsgi.py': mod_wsgi.c:Adapt=
>er_run: PyErr_Occurred 1.
>[Wed Nov 14 21:24:52.014311 2018] [wsgi:error] [pid 19848] [remote 10.146.1=
>22.53:52967] RuntimeError: response has not been started
>
>The part I added says the file (mod_wsgi.c) and function (Adapter_run) wher=
>e the error is detected. The '1' is there because there is a similar proble=
>m in the same function. It is used to distinguish the two cases. TWE1 tells=
> me which log message is generated. There are 2. The other 29 places call t=
>he logging function in wsgi_logger.c
>
>
>The mod_wsgi module is written in C. It loads and executes Python code usin=
>g the Python C API.
>
>
>I can display the demo tracker's home page, create an issue and modify
>attributes on the issue. I can create and modify users. When I try to
>add a Change Note on an issue with a nosy filled in, I get the
>Internal Server Error. Doing an import on demo_wsgi generates no errors.
>The demo_wsgi.py file specifically sets sys.path to the virtualenv
>Python directory. It imports roundup successfully which is only
>installed in the virtualenv.
>
>Having mod_wsgi generate a stack trace, and maybe even the error code would
>be nice, but I don't know how to do that using the Python C API.
>
>When you encounter mod_wsgi errors like this, what do you do?

I am speaking off the cuff here, but does:

  https://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html

help any? Maybe wrap the application call in the demo_wsgi python
script in try/except and capture everything decoding the exception and
writing it to wsgi.errors?


It also discusses error catching middleware that writes to wsgi.errors
object. Also it discusses using gdb to debug/dump stack traces which
seems to be what you are looking for.

Good luck in your bug hunt.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.