I think you may have hit the nail on the head. The problem only comes
up when I'm trying to serve Mercurial repos on the same server and, I
discovered after I emailed, it happens whether I use mod_python or
mod_wsgi for Trac.
Think it's the case that Mercurial and Trac use the same C extension?
If it is, do I just set both Mercurial and Trac to use %{GLOBAL} ?
Thanks for all the help. I really appreciate it!
On Mon, Oct 6, 2008 at 4:50 AM, Graham Dumpleton
<[EMAIL PROTECTED]> wrote:
>
> BTW, one of the possible causes of your problem could be the use of a
> third party C extension module that doesn't work properly for multiple
> sub interpreters. Yes, I know that Trac may be running with
> WSGIApplicationGroup of %{GLOBAL}, but if that same C extension module
> is being used in Django in a different interpreter, the C extension
> module may be incorrect caching in a static global C variable a Python
> object, which it then incorrectly uses across multiple sub
> interpreters. The psycopg2 package has this problem for a period, so
> ensure that any C extension modules you are using in any of your
> applications are the latest.
>
> Also, you probably avoid the problem by using WSGIDaemonProcess to
> create separate daemon process groups and delegate each application to
> run in its own daemon process group. For best chance of everything
> working, use WSGIApplicationGroup with %{GLOBAL} so each application
> runs in main interpreter of their respective daemon process groups.
>
> Graham
>
> 2008/10/6 Graham Dumpleton <[EMAIL PROTECTED]>:
>> 2008/10/6 Todd O'Bryan <[EMAIL PROTECTED]>:
>>>
>>> Sorry, but where do I look for the stack trace?
>>>
>>> I did find this in the error_log,
>>
>> Hmmm, where were you seeing the error message in the first place? Was
>> Trac catching the exception and generating a special Trac error page
>> to the browser. If this is the case, am not sure where Trac may log
>> full exception traceback. You would need to ask Trac folks where more
>> information about internal exceptions are logged.
>>
>> If the exception was being caught by Trac but was propagating all the
>> way back up to mod_wsgi, then there full error should appear in either
>> the main Apache error log file, or if using ErrorLog directive inside
>> in VirtualHost, then in virtual host specific error log file.
>>
>>> but it's weird because I'm using
>>> Ubuntu with the package system, so it really should have sorted this
>>> out, I think.
>>>
>>> [Mon Oct 06 00:42:39 2008] [warn] mod_wsgi: Compiled for Python/2.5.1.
>>> [Mon Oct 06 00:42:39 2008] [warn] mod_wsgi: Runtime using Python/2.5.2.
>>
>> That can be ignored, provided Python is a shared library, as only
>> relates to minor patch revision.
>>
>> This is talked about in:
>>
>>
>> http://code.google.com/p/modwsgi/wiki/InstallationIssues#Python_Version_Mismatch
>>
>> Graham
>>
>>> On Sun, Oct 5, 2008 at 8:53 PM, Graham Dumpleton
>>> <[EMAIL PROTECTED]> wrote:
>>>>
>>>> Can you supply the full Python traceback from the Apache error log file?
>>>>
>>>> Graham
>>>>
>>>> 2008/10/6 Todd O'Bryan <[EMAIL PROTECTED]>:
>>>>>
>>>>> Here are the relevant parts of my httpd.conf file, I think.
>>>>>
>>>>> WSGIScriptAlias /trac /srv/trac/trac.wsgi
>>>>> <Location /trac>
>>>>> WSGIApplicationGroup %{GLOBAL}
>>>>> </Location>
>>>>>
>>>>> # <Location "/trac">
>>>>> # SetHandler mod_python
>>>>> # PythonInterpreter main_interpreter
>>>>> # PythonHandler trac.web.modpython_frontend
>>>>> # PythonOption TracEnvParentDir /srv/trac
>>>>> # PythonOption TracUriRoot /trac
>>>>> # </Location>
>>>>>
>>>>> <LocationMatch "/trac/[^/]+/login">
>>>>> AuthType Basic
>>>>> AuthName "Trac"
>>>>> AuthUserFile /srv/trac/.htpasswd
>>>>> Require valid-user
>>>>> </LocationMatch>
>>>>>
>>>>>
>>>>> On Sun, Oct 5, 2008 at 8:31 PM, Graham Dumpleton
>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>> 2008/10/6 Todd O'Bryan <[EMAIL PROTECTED]>:
>>>>>>>
>>>>>>> I just started hosting some Mercurial repositories on my server with
>>>>>>> mod_wsgi, and, maybe coincidentally, my Trac setup has started
>>>>>>> throwing the very popular RuntimeError: instance.__dict__ not
>>>>>>> accessible in restricted mode.
>>>>>>>
>>>>>>> Since it had never done that before, I thought the problem might be a
>>>>>>> problem with mod_wsgi and mod_python, so I switched Trac to use
>>>>>>> mod_wsgi, and the problem still shows up.
>>>>>>>
>>>>>>> I'm currently hosting a couple of Django apps and some SVN repos on
>>>>>>> the same server, so it could be stupidity on my part, but I haven't
>>>>>>> seen any reports of mod_wsgi causing this problem on Trac, so I
>>>>>>> suspect there may be a subtle problem.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>
>>>>>> What are you setting WSGIApplicationGroup directive to? See:
>>>>>>
>>>>>>
>>>>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Multiple_Python_Sub_Interpreters
>>>>>>
>>>>>> 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
-~----------~----~----~----~------~----~------~--~---
