Logging/exception details from global module scope not showing in Apache error log.

[GoogleCodeExporter]

Was reported by one user via direct email, that they were not seeing anything 
in Apache log files 
corresponding to a Python exception occurring when WSGI script file was first 
being loaded. This 
only occurred when using daemon mode. Their particular configuration had the 
form:

  LogLevel warn
  ErrorLog ...

  <VirtualHost ...>
  WSGIDaemonProcess ...
  WSGIProcessGroup

  LogLevel info
  ErrorLog ...
  </VirtualHost>

They actually had a number of other virtual hosts defined as well.

Attempts to duplicate problem found nothing wrong.

Overall, not known 100% whether they were simply looking in the wrong log files 
given that there 
would be two involved here, the main Apache error log file and the virtual host 
specific log file. 
Information being supplied back at times suggested wrong log files may have 
been looked at, 
but because LogLevel was only set to warn outside of virtual hosts, hard to 
confirm that based on 
information supplied.

Although no one else has reported such a problem, logging issue just to track 
anything related to 
logging problems like this. Will over time attach test programs and procedures 
to help verify if 
logging is coming out as expected.

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 26 Apr 2008 at 4:45

[GoogleCodeExporter]

From investigation of this issue, one thing that has come up is that in 
mod_wsgi code, it may be necessary to 
forcibly flush any error output object to which exceptions occurring on import 
are displayed. Although error 
output object will automatically flush on newline, it is technically possible 
that if the whole exception 
message was on one line with now newline terminator, it wouldn't be flushed 
until error output object is 
destroyed. Normally the error output object would be destroyed immediately 
after exception traceback is 
generated, but if for some reason Python code was holding a reference to error 
output object this wouldn't 
occur as the flushing is done from destructor of error output object.

At this stage this isn't seen as being able to cause a loss of data though, as 
Python exception tracebacks 
normally span may lines with embedded and closing newline. As a result any data 
would have been flushed 
anyway. At worst case this would only result in last output line not being 
displayed immediately and not the 
loss of all output.

Original comment by Graham.Dumpleton@gmail.com on 26 Apr 2008 at 4:50

[GoogleCodeExporter]

More reports of similar problems. See thread:

  http://groups.google.com/group/modwsgi/browse_frm/thread/9f77352df34cd684

Original comment by Graham.Dumpleton@gmail.com on 30 Apr 2008 at 12:49

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 30 Apr 2008 at 12:49

• Added labels: Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

I can give you account on my host for debugging this problem. Plz tell me if you
cannot reproduce it.

Original comment by img...@gmail.com on 11 May 2008 at 7:48

[GoogleCodeExporter]

If the host definitely shows problem, would be great. Someone else gave me 
access to a newly constructed host 
to debug the problem, but the newly constructed host doesn't exhibit the 
problem like his original host setup 
was doing. Send any details of hosts/account direct to me on my gmail account.

Original comment by Graham.Dumpleton@gmail.com on 11 May 2008 at 8:02

[GoogleCodeExporter]

A quick workaround, albeit with caveats, for this issue should be to find line:

  ap_update_vhost_from_headers(r);

in source code and immediately after that line add:

      r->server = wsgi_server;

For the case where WSGIDaemonProcess appears inside of VirtualHost, and 
ErrorLog is also specified inside of the VirtualHost, this 
should see all logging correctly go to the VirtualHost error log.

The caveat though is that if WSGIDaemonProcess is defined outside of 
VirtualHost context, because you wanted to be able to 
associate two WSGI applications running under different VirtualHost contexts, 
with the same Python interpreter instance in a 
specific daemon process, then the logging from both WSGI applications will go 
to main Apache error log rather than an error log 
associated with the VirtualHost the request was being handled under.

In this latter case, it was a strange case anyway, as by having 
WSGIDaemonProcess outside of all VirtualHosts, the output sent to 
stderr/stdout would go to the main Apache error log, but output to wsgi.errors 
and any uncaught errors from executing a request 
would go to the VirtualHost error log if specified. Thus you had to look in two 
different places.

Because of this split in where things went, it may actually be more sensible to 
make the workaround the actual fix, meaning that 
all error output from WSGIDaemonProcess when outside of VirtualHost would 
consistently go to same place, ie. main Apache error 
log.

Note, the workaround is actually untested at this point. :-)

Original comment by Graham.Dumpleton@gmail.com on 11 May 2008 at 10:28

[GoogleCodeExporter]

Possible more permanent fix for this. In mod_wsg.c search for REQUEST_NO_BODY. 
You will find code:

    r->read_body = REQUEST_NO_BODY;

    r->status = HTTP_INTERNAL_SERVER_ERROR;

Change the latter line so it reads:

    r->read_body = REQUEST_NO_BODY;

    r->status = HTTP_OK;

That is, change what r->status is initialised to, to HTTP_OK instead of 
HTTP_INTERNAL_SERVER_ERROR.

Down in Apache code where it does vhost mapping to server_rec, it was checking 
r->status and if it wasn't 
HTTP_OK was assuming an error had occurred earlier and that it could stop and 
not bother doing what it was 
meant to. :-(

Original comment by Graham.Dumpleton@gmail.com on 12 May 2008 at 12:05

[GoogleCodeExporter]

Fix incorporated in mod_wsgi 1.4 and 2.1.

Would still like to get some more confirmation that fix does in fact address 
problem.

Original comment by Graham.Dumpleton@gmail.com on 7 Jul 2008 at 2:17

• Changed state: Fixed

[GoogleCodeExporter]

Had the same problem when using version 2.0, now using 2.8 and the problem has 
gone

Original comment by sk8board...@gmail.com on 16 Dec 2010 at 12:49