[modwsgi] Re: threading.local
Failed requests:9993 But I did have 1564.21 requests per second doh :-) anyway http://87.98.218.86/gil.py seem to work ? http://87.98.218.86/bench.txt (added my apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? --~--~-~--~~~---~--~~ 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: threading.local
On Oct 6, 10:18 am, Graham Dumpleton [EMAIL PROTECTED] wrote: 2008/10/6 gert [EMAIL PROTECTED]: Failed requests: 9993 But I did have 1564.21 requests per second doh :-) anywayhttp://87.98.218.86/gil.pyseem to work ? http://87.98.218.86/bench.txt(added my apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? No one will never know because you never post enough information. If the script is generating a 500 error response, what was the traceback or other error in the Apache error log? Have you tried to debug what was causing the error? Graham I have alot of this [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py,line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT testFROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. Cool I noticed that pressing f5 it sometimes works and sometimes doesn't lol :) :) :) when it works i get [Mon Oct 06 10:30:46 2008] [info] [client 80.200.216.121] mod_wsgi (pid=1542, process='', application=''): Loading WSGI script '/srv/www/ gil.py'. When it doesnt i get [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py,line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT testFROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. --~--~-~--~~~---~--~~ 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
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: threading.local
On Oct 6, 10:33 am, gert [EMAIL PROTECTED] wrote: On Oct 6, 10:18 am, Graham Dumpleton [EMAIL PROTECTED] wrote: 2008/10/6 gert [EMAIL PROTECTED]: Failed requests: 9993 But I did have 1564.21 requests per second doh :-) anywayhttp://87.98.218.86/gil.pyseemto work ? http://87.98.218.86/bench.txt(addedmy apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? No one will never know because you never post enough information. If the script is generating a 500 error response, what was the traceback or other error in the Apache error log? Have you tried to debug what was causing the error? Graham I have alot of this [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py, line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT test FROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. Cool I noticed that pressing f5 it sometimes works and sometimes doesn't lol :) :) :) when it works i get [Mon Oct 06 10:30:46 2008] [info] [client 80.200.216.121] mod_wsgi (pid=1542, process='', application=''): Loading WSGI script '/srv/www/ gil.py'. When it doesnt i get [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py, line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT test FROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. This is what i get in gdb with cflag -g in make file Starting program: /usr/sbin/apache2 -X (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 0x7f304cb12760 (LWP 6503)] (no debugging symbols found) (no debugging symbols found) It seems that gil.py will work one time and then stops working until you reloading the WSGI script --~--~-~--~~~---~--~~ 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: threading.local
On 06-10-2008, gert wrote: On Oct 6, 10:33 am, gert [EMAIL PROTECTED] wrote: On Oct 6, 10:18 am, Graham Dumpleton [EMAIL PROTECTED] wrote: 2008/10/6 gert [EMAIL PROTECTED]: Failed requests: 9993 But I did have 1564.21 requests per second doh :-) anywayhttp://87.98.218.86/gil.pyseemto work ? http://87.98.218.86/bench.txt(addedmy apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? No one will never know because you never post enough information. If the script is generating a 500 error response, what was the traceback or other error in the Apache error log? Have you tried to debug what was causing the error? Graham I have alot of this [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py, line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT test FROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') You have an InterfaceError, then, look also at the log of your database server... Did you loose the connection ? Did you share a not thread safe connection ? -- William Dodé - http://flibuste.net Informaticien Indépendant --~--~-~--~~~---~--~~ 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] file http_filters.c, line 346, assertion readbytes 0 failed
Hi,
[Mon Oct 06 15:08:52 2008] [notice] Apache/2.2.4 (Linux/SUSE)
mod_ssl/2.2.4 OpenSSL/0.9.8e mod_wsgi/2.3 Python/2.5.1 configured --
resuming normal operations
[Mon Oct 06 15:09:01 2008] [crit] [Mon Oct 06 15:09:01 2008] file
http_filters.c, line 346, assertion readbytes 0 failed
[Mon Oct 06 15:09:02 2008] [notice] child pid 18551 exit signal Aborted (6)
I run apache2-mod_wsgi-2.3-1.2 on Suse 10.3
The RPM is from: http://software.opensuse.org/search?q=mod_wsgi
The result is reproducable. It happens after sever start/stop and
everytime I submit the form.
The form looks like this:
form action=./ method=post
input type=hidden name=dummy_value value=1
input type=submit value=do it
/form
If I remove the hidden input 'dummy_value', the error does not occur.
Do you need any additional information?
Thomas Güttler
Apache config
WSGIDaemonProcess django_myapp_comp user=myapp group=users threads=1
processes=2 maximum-requests=1
WSGIScriptAlias /myapp /home/myapp/myapp_comp/apache/django_wsgi.py
Location /myapp/
WSGIProcessGroup django_myapp_comp
WSGIApplicationGroup %{GLOBAL}
# Mit einem touch auf das WSGIScript wird alles neu gestartet
WSGIReloadMechanism Process
AuthType Basic
AuthUserFile ...
AuthGroupFile ...
AuthName ...
## Keine Einschränkung anhand der IP
Order deny,allow
Allow from all
require valid-user
Satisfy All
/Location
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
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: threading.local
On 06-10-2008, William Dode wrote: ... The only problem is that there is not a lot of db pool utilities and dbutils is one of the most famous... I reported the problem on the dbutils list -- William Dodé - http://flibuste.net Informaticien Indépendant --~--~-~--~~~---~--~~ 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: threading.local
On 04-10-2008, Graham Dumpleton wrote:
BTW, if I am right, you would see the behaviour you expect to see if you use:
WSGIApplicationGroup %{GLOBAL}
More or less, it give me alternatively two differents local instances...
But i'm agree with your analyze, that to use threading.local is not
reliable. It's ok to keep the connection for the time of the request but
not for a persistent pool between requests. It's just to know about it.
The only problem is that there is not a lot of db pool utilities and
dbutils is one of the most famous...
--
William Dodé - http://flibuste.net
Informaticien Indépendant
--~--~-~--~~~---~--~~
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: Segmentation fault - premature end of script headers
2.0.8 definitely fixed some segfaults on my end.
So far, since September 30 I have not seen any segmentation faults.
Seems that upgrade to 2.0.8 and using %{GLOBAL} solved the problem.
Graham, thank you for the support! :)
--
Maciej Wisniowski
--~--~-~--~~~---~--~~
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: threading.local
Will this share connections between requests ?
import _mysql
db = _mysql.connect('127.0.0.1','root','root','www')
def application(environ, start_response):
db.query(SELECT test FROM test)
row = db.store_result()
v = row.fetch_row()[0][0]
db.close()
response_headers = [('Content-type', 'text/html'),('Content-
Length', str(len(v)))]
start_response('200 OK', response_headers)
return [v]
--~--~-~--~~~---~--~~
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: threading.local
On Oct 6, 11:48 pm, gert [EMAIL PROTECTED] wrote:
Will this share connections between requests ?
import _mysql
db = _mysql.connect('127.0.0.1','root','root','www')
def application(environ, start_response):
db.query(SELECT test FROM test)
row = db.store_result()
v = row.fetch_row()[0][0]
db.close()
response_headers = [('Content-type', 'text/html'),('Content-
Length', str(len(v)))]
start_response('200 OK', response_headers)
return [v]
nope it gives the exact same result, works one time and after the
first request you get
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91] Traceback
(most recent call last):, referer: http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91] File /srv/
www/gil.py, line 12, in application, referer: http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91]
db.query(SELECT test FROM test), referer: http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91]
InterfaceError: (0, ''), referer: http://87.98.218.86/
so can you make modwsgi share global variables between requests ?
--~--~-~--~~~---~--~~
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: threading.local
2008/10/6 gert [EMAIL PROTECTED]: On Oct 6, 10:33 am, gert [EMAIL PROTECTED] wrote: On Oct 6, 10:18 am, Graham Dumpleton [EMAIL PROTECTED] wrote: 2008/10/6 gert [EMAIL PROTECTED]: Failed requests:9993 But I did have 1564.21 requests per second doh :-) anywayhttp://87.98.218.86/gil.pyseemto work ? http://87.98.218.86/bench.txt(addedmy apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? No one will never know because you never post enough information. If the script is generating a 500 error response, what was the traceback or other error in the Apache error log? Have you tried to debug what was causing the error? Graham I have alot of this [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py,line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT testFROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. Cool I noticed that pressing f5 it sometimes works and sometimes doesn't lol :) :) :) when it works i get [Mon Oct 06 10:30:46 2008] [info] [client 80.200.216.121] mod_wsgi (pid=1542, process='', application=''): Loading WSGI script '/srv/www/ gil.py'. When it doesnt i get [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py,line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT testFROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. This is what i get in gdb with cflag -g in make file Which says absolutely nothing. Just because I suggested to someone else that gdb could be used to debug an issue, doesn't mean it is then a magic bullet that is applicable to every situation. It will only be of use it quite specific situations. I sincerely hope that the debug suggestions you give to people will not now expand to, 'replace your whole Apache configuration with yours' and 'run gdb to work out problem'. Both suggestions aren't helpful. :-) Graham Starting program: /usr/sbin/apache2 -X (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 0x7f304cb12760 (LWP 6503)] (no debugging symbols found) (no debugging symbols found) It seems that gil.py will work one time and then stops working until you reloading the WSGI script --~--~-~--~~~---~--~~ 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
