Believe this should all now be fixed on develop branch of mod_wsgi. Please test and let me know if is now working as you expect so I can get a new release out.
If anyone is able to test off develop with Apache 2.0 and 2.2 (not just 2.4), that would be most appreciated. Graham > On 6 Aug 2016, at 3:32 PM, Graham Dumpleton <[email protected]> > wrote: > > Getting closer. Anything output to sys.stdout and sys.stderr from within a > request handler will now be routed via wsgi.errors. Your %L format will work. > The remote address shows IP correctly, but is not showing the remote port > correctly, instead showing 0. > > Please start testing using develop branch and let me know of any unexpected > problems. > > Graham > >> On 6 Aug 2016, at 1:59 PM, Graham Dumpleton <[email protected] >> <mailto:[email protected]>> wrote: >> >> So I have it sort of working when using stdout/stderr, but there is one >> issue which means still need to do some work if can decide what should be >> done. >> >> niaZC/85C0Q AH01628: authorization result: granted (no directives) >> niaZC/85C0Q AH01628: authorization result: granted (no directives) >> niaZC/85C0Q global message >> niaZC/85C0Q request message >> >> X+fwC/85C0Q AH01628: authorization result: granted (no directives) >> X+fwC/85C0Q AH01628: authorization result: granted (no directives) >> X+fwC/85C0Q queued messageglobal message >> X+fwC/85C0Q request message >> >> The problem is the ‘queued message’. This is with application of: >> >> def application(environ, start_response): >> print('global message') >> print('request message', file=environ['wsgi.errors']) >> print('queued message', end=‘') >> >> The ‘queued message’ is one which there was no newline terminator. >> >> What normally occurs is that messages get buffered up until a newline >> terminator is encountered, which then acts to flush it out and write it to >> Apache log API. This is important else if you do something like: >> >> print(1, 2, 3, 4) >> >> They will all get printed on separate log lines, which isn’t what you would >> expect. >> >> The log ID only gets pulled in when you thus flush out what is buffered. >> >> There a couple of problems around this. >> >> Each of those numbers in that last print() statement get buffered >> separately. If another request handler does the same thing, they can get >> interleaved, as there is only one stdout. When they get flushed out, the log >> ID will be for whatever request sent the newline first. This data will get >> attributed against wrong request. >> >> Similar issue is where a request never sent a new line like above, in this >> case it ends up at start of data for next request. >> >> One solution which should work out reasonably cleanly is that if in a >> request, reach back and grab wsgi.errors and divert output via that, which >> is per request and is flushed at the end of the request. At least I think >> that will work. >> >> More later. >> >> Graham >> >>> On 5 Aug 2016, at 11:34 PM, Graham Dumpleton <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On 5 Aug 2016, at 10:18 PM, Graham Dumpleton <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On 5 Aug 2016, at 9:54 PM, Stefan Nastic <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Is there a way to configure the logging with mod_wsgi and Django without >>>>> losing the request information, such as remote client IP or unique log ID >>>>> AND without using environ['wsgi.errors']? Other solutions such as logging >>>>> wrapper would be also acceptable... >>>>> >>>>> Please also see related SO discussions: >>>>> http://stackoverflow.com/questions/38786532/logging-with-apache-2-4-mod-wsgi-and-django >>>>> >>>>> <http://stackoverflow.com/questions/38786532/logging-with-apache-2-4-mod-wsgi-and-django> >>>>> http://stackoverflow.com/questions/38767989/apache-2-4-error-log-entries-incomplete >>>>> >>>>> <http://stackoverflow.com/questions/38767989/apache-2-4-error-log-entries-incomplete> >>>> >>>> Short answer, no. >>>> >>>> The two basic problems are detailed in: >>>> >>>> https://github.com/GrahamDumpleton/mod_wsgi/issues/144 >>>> <https://github.com/GrahamDumpleton/mod_wsgi/issues/144> >>>> https://github.com/GrahamDumpleton/mod_wsgi/issues/145 >>>> <https://github.com/GrahamDumpleton/mod_wsgi/issues/145> >>>> >>>> but the solution even for the first is far from simple. >>>> >>>> The problem is that the request and connection log IDs are only generated >>>> the first time a message is logged via the Apache log API. In the case of >>>> proxying a request from the Apache child worker process to a daemon mode >>>> process, there wouldn’t have been any messages logged and so nothing has >>>> triggered the generation of the log IDs. This means they aren’t available >>>> to transfer across to the daemon process such that they could be >>>> reconstructed into the connection and request records to fake up things so >>>> that logging works in daemon mode. A solution may be for mod_wsgi to >>>> forcibly cause the generation of the log IDs on every request using an >>>> Apache API call, even though they may not be required. The implications of >>>> doing this need to be looked at. Alternatively, one works out what seed >>>> information from a request is used to generate the log ID so can ensure >>>> that is being passed across and added to the fake connection and request >>>> objects that the logging will eventually use. >>> >>> Copying across underlying seed information isn’t possible because part of >>> the calculation involves turning a C pointer to a data structure for the >>> thread into an integer. One can’t set the C pointer to same value of daemon >>> process side because if something then tries to access via it, process will >>> crash. >>> >>> It is possible to force the generation of the connection and request IDs >>> though if not already set and pass those across. Luckily is not so hard. >>> >>> The develop branch of the repo now has changes which will do that at least, >>> with the connection and request ID available in the per request WSGI >>> environ dictionary as mod_wsgi.connection_id and mod_wsgi.request_id. Any >>> messages logged via wsgi.errors will now show the correct log ID. >>> >>>> You also keep saying remote client IP doesn’t show. On my testing on MacOS >>>> X it does and the client IP is transferred across to daemon mode, so not >>>> sure what the issue is there as cannot replicate it at this point. >>>> >>>> So trying to address even the log ID issues for wsgi.errors is going to >>>> take some time and work. Linking messages to stdout/stderr back to >>>> requests is going to be even more complicated. >>> >>> >>> The stdout/stderr issues needs more investigation. One thing in our favour >>> is that I had already added a thread local for tracking request state due >>> to metrics collection. I don’t know that that gives access to the raw >>> Apache request object though which is needed, so would likely need >>> extending. >>> >>> If you really need something though, you can try caching those IDs from the >>> per request WSGI environ dictionary and using those in messages somehow. >>> >>> Graham >> > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
