Thank you, thank you, thank you! I'll give this a try tonight and see
how long before someone tells me Trac is down. :-)
On Mon, Oct 6, 2008 at 9:08 PM, Graham Dumpleton
<[EMAIL PROTECTED]> wrote:
>
> 2008/10/7 Todd O'Bryan <[EMAIL PROTECTED]>:
>>
>> 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} ?
>
> I have not heard any problems with Mecurial and Trac residing in same
> interpreter instance, so yes, setting WSGIApplicationGroup to be
> %{GLOBAL} for both should be okay.
>
> Preferably though, use WSGIDaemonProcess/WSGIProcessGroup to delegate
> each to a separate daemon process group at the same time.
>
> One way of doing that would be:
>
> WSGIDaemonProcess trac
> WSGIDaemonProcess mercurial
>
> WSGIScriptAlias /trac /some/path/trac.wsgi
>
> <Location /trac>
> WSGIProcessGroup trac
> WSGIApplicationGroup %{GLOBAL}
> </Directory>
>
> WSGIScriptAlias /mercurial /some/path/mercurial.wsgi
>
> <Directory /mercurial>
> WSGIProcessGroup mercurial
> WSGIApplicationGroup %{GLOBAL}
> </Directory>
>
> Graham
>
>> 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
-~----------~----~----~----~------~----~------~--~---
