2009/7/9 David Cramer <[email protected]>:
>
> We are running the aptitude package (in Ubuntu) which says "Version:
> 2.3-1build1". As far as the global interpreter goes our config looks
> like this:
>
> WSGIScriptAlias / /home/ibegin/iplatform/handler.wsgi
> WSGIDaemonProcess www.ibegin.com display-name=ibegin.com
> processes=3 threads=10 stack-size=512kb deadlock-timeo$
> WSGIProcessGroup www.ibegin.com
>
> I didn't quite understand in your post if you are suggested to add the
> global flag, or just leave the default.
The default is actually:
WSGIApplicationGroup %{RESOURCE}
This in simple case of 80/443 ports, equates to a named sub
interpreter being used with name composed from:
SERVER_NAME|SCRIPT_NAME
That is, combination of name of virtual host and the mount point of
the WSGI application.
Because it is a named sub interpreter, it is actually a Python sub
interpreter within the same process.
So, what I want you to do is override this default and explicitly define:
WSGIApplicationGroup %{GLOBAL}
The value '%{GLOBAL}' effectively gets internally expanded to be empty
string, ie., '', which in mod_wsgi is used to refer to the main Python
interpreter. That is, the interpreter that was created when
Py_Initialize() was called.
The main Python interpreter is special in as much as third party C
extension modules which use simplified GIL state API will only work
properly in Python main interpreter. There are also other things C
extension modules can do which will also cause them not to work in a
Python sub interpreter, but will still work in the Python main
interpreter.
In delegating WSGI application to main Python interpreter within the
process, does mean that that should be only WSGI application delegated
to that daemon process group, unless you qualify use of
WSGIApplicationGroup within Directory or Location container to say it
only applies to a specific application delegated to that daemon
process group.
Anyway, since it is moderately reproducible, just add:
WSGIApplicationGroup %{GLOBAL}
and see if you can still trigger it. That will at least answer
question of whether it helps.
As I said before, my recollection is that when using GeoDjango that
you need to do this.
Graham
> If the bug which you are referring to only happens when a request is
> cancelled that wouldn't be our issue. Im personally reproducing these
> in the browser, and it's a full page load which ends up with a default
> Apache ISE page, and a useless message in the error.log (thus the
> reason this is such an issue for us, we're unable to debug anything we
> can't reproduce).
>
> On Jul 8, 7:37 pm, Graham Dumpleton <[email protected]>
> wrote:
>> 2009/7/9 David Cramer <[email protected]>:
>>
>>
>>
>>
>>
>> > We're having some issues with the dread seg faults. I've been going
>> > through the checklist and so far I'm not finding anything.
>>
>> > It happens in 2 specific areas right now:
>> > - MySQLdb throwing a warning.
>> > - Geodjango throwing an error in it's __del__ (sys.stderr).
>>
>> > I believe this may be entirely with __del__'s but I'm not sure how
>> > internals of MySQLdb work. I've confirmed expat and mysqldb are the
>> > same. We had no mysql db module for apache, but I'm guessing that's
>> > not abnormal. I've also confirmed that mod_python is uninstalled so
>> > there should be no conflicts from there.
>>
>> > The two specific things we see in apache are:
>>
>> > - [Mon Jul 06 10:10:57 2009] [error] [client 207.97.218.238] Premature
>> > end of script headers: handler.wsgi
>> > - [Mon Jul 06 10:10:57 2009] [notice] child pid 32555 exit signal
>> > Segmentation fault (11)
>>
>> Hi David, saw your posts on #django about white 500 pages. Been
>> meaning to drop you an email about it and see what it was about.
>>
>> A couple of questions.
>>
>> First, which version of mod_wsgi are you using?
>>
>> Second, are you using:
>>
>> WSGIApplicationGroup %{GLOBAL}
>>
>> to ensure that Django running in main interpreter inside of the daemon
>> process you are delegating it to?
>>
>> My understanding is that parts of GeoDjango, or things it uses, will
>> not work in Python sub interpreters and so necessary to force it to
>> run in Python main interpreter, which for mod_wsgi is don't use the
>> above WSGIApplicationGroup directive and setting it to '%{GLOBAL}'.
>>
>> There is also one known cause of a segmentation fault in daemon mode
>> with current 2.X release tar balls. It only happens in rare
>> circumstances as it is dependent on client closing connection at
>> specific point in between Apache accepting request and WSGI
>> application making first attempt to read request content. The patch
>> for this issue is:
>>
>> Index: mod_wsgi.c
>> ===================================================================
>> --- mod_wsgi.c (revision 1351)
>> +++ mod_wsgi.c (revision 1352)
>> @@ -1540,7 +1540,6 @@
>>
>> if (n == -1) {
>> PyErr_SetString(PyExc_IOError, "request data read error");
>> - Py_DECREF(result);
>> return NULL;
>> }
>>
>> In your case you seem to have associated problem with one of those
>> third party packages, so this latter problem may not be cause and may
>> be sub interpreter issue.
>>
>> Graham
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---
