Hi,
sorry for a bit delayed response, but I was traveling the last week and had
a very limited internet connectivity.
Now back to the issue. I tested the version 4.5.4 and in short there is
some problem as I get seg fault in the apache. I have checked 4.5.4. for
the most common issues such as loading mod_python, linking against shared
libraries, etc. and there everything seam to be fine. I have also tested
the same compilation and installation procedure with 4.5.3 and it works
fine.
So I suspect that this is a codding error, most probably accessing the
protected memory region when you try to access/reproduce Log ID seed.
However, this is only my assumption since I have not had a chance to look
at your code.
For debugging purposes ....
Apache error log:
[mpm_event:notice] [pid 25563:tid 140401132873600] AH00494: SIGHUP
received. Attempting to restart
[mpm_event:notice] [pid 25563:tid 140401132873600] AH00489: Apache/2.4.10
(Debian) mod_wsgi/4.5.4 Python/3.4.2 configured -- resuming normal
operations
[core:notice] [pid 25563:tid 140401132873600] AH00094: Command line:
'/usr/sbin/apache2'
[core:notice] [pid 25563:tid 140401132873600] AH00052: child pid 27051 exit
signal Segmentation fault (11)
OS: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29)
x86_64 GNU/Linux
APACHE:
Server version: Apache/2.4.10 (Debian)
Server built: Nov 28 2015 14:05:48
Server's Module Magic Number:
Server loaded: APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"
Python:
Python 3.4.2
Linked libs for mod_wsgi.so:
linux-vdso.so.1 (0x00007ffd436c5000)
libpython3.4m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
(0x00007f79fea6f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f79fe852000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f79fe64e000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f79fe44b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f79fe14a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f79fdd9f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f79fdb97000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f79fd96e000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f79fd753000)
/lib64/ld-linux-x86-64.so.2 (0x00007f79ff2ea000)
Hope this helps!
Best,
Stefan
On Sunday, August 7, 2016 at 2:16:31 AM UTC+2, Graham Dumpleton wrote:
>
> 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]
> <javascript:>> 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]
> <javascript:>> 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]
> <javascript:>> wrote:
>
>
> On 5 Aug 2016, at 10:18 PM, Graham Dumpleton <[email protected]
> <javascript:>> wrote:
>
>
> On 5 Aug 2016, at 9:54 PM, Stefan Nastic <[email protected]
> <javascript:>> 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/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/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.
