[modwsgi] Re: RuntimeError with Trac
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 modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: RuntimeError with Trac
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
[modwsgi] Re: RuntimeError with Trac
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 modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: RuntimeError with Trac
Sorry, but where do I look for the stack trace? I did find this in the error_log, 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. 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 modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---