Graham Dumpleton wrote:
> 2009/1/5 Alberto Valverde <[email protected]>:
>
>> Sanjiv wrote:
>>
>>> Hi Alberto,
>>>
>>> I am getting an Internal Server Error occasionally. I remember this
>>> used to happen in the old server too initially and then you fixed
>>> something.
>>>
>>>
>> Under http://toscawidgets.org/trac/ right?
>>
>> The old server was using mod_wsgi originally but switched to paste
>> because of this (and my lack of time to properly help debug it), I've
>> upgraded to latest mod_wsgi stable release (2.3) hoping it would have
>> been solved but it unfortunately it seems that it isn't... :(
>>
>> I suspect it might have something to do with the apache bundled in
>> debian etch since it's what both my server and TG's are using. Other
>> Tracs I've deployed with mod_wsgi in Ubuntu 8.04 haven't had any
>> problems yet.
>>
>> I hope to be able to spare an afternoon to collect proper debugging info
>> and report to mod_wsgi's ML soon... Well, cc'ing anyway in case this is
>> a known issue...
>>
>
> Can you start the ball rolling by posting up the Apache/mod_wsgi
> configuration you are using so can see whether using embedded mode or
> daemon mode and whether forcing Trac to run in first interpreter
> instance? Also indicate which database and adapter you are using,
> including versions so can see if they are any of those for which
> problems have been found in the past. Finally, indicate whether either
> mod_python of PHP are being loaded into same Apache.
>
Sure:
------------------------------------- VHOST file
----------------------------------------------------------------
NameVirtualHost *
<VirtualHost *>
ServerName www.toscawidgets.org
RedirectMatch ^(.*)$ http://toscawidgets.org$1 301
</VirtualHost>
<VirtualHost *>
ServerAdmin [email protected]
ServerName toscawidgets.org
WSGIPassAuthorization On
# http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives
WSGIDaemonProcess prod.toscawidgets.org \
user=toscawidgets \
group=toscawidgets \
processes=5 \
threads=10 \
python-path=/home/www/toscawidgets/lib/twWebSite/lib/python2.5/site-packages/
\
stack-size=524288
WSGIDaemonProcess widgetbrowser.toscawidgets.org \
user=toscawidgets \
group=toscawidgets \
processes=1 \
threads=10 \
python-path=/home/www/toscawidgets/lib/WidgetBrowser/lib/python2.5/site-packages/
\
stack-size=524288
<Location />
WSGIProcessGroup prod.toscawidgets.org
</Location>
<Location /widget/>
WSGIProcessGroup widgetbrowser.toscawidgets.org
</Location>
WSGIScriptAlias /widget /home/www/toscawidgets/wsgi/widgetbrowser.wsgi
WSGIScriptAlias / /home/www/toscawidgets/wsgi/twWebSite.wsgi
ErrorLog /home/www/toscawidgets/var/log/error.log
CustomLog /home/www/toscawidgets/var/log/access.log combined
</VirtualHost>
Trac isn't being forced, AFAIK, to be run in the first interpreter. I've
just added:
WSGIApplicationGroup %{GLOBAL}
under the "/" Location section (where trac runs at) to see if it makes a
difference, I'll report back later today.
I think it's worth noting that Trac is not mounted in the conventional
way (as described in
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac) but it runs
within a Pylons app (this is the code of the relevant controller in case
it helps [1])
Database is postgresql 8.1 from debian etch (8.1.11-0etch1) and adapter
is psycopg2 2.0.8 compiled from source for py2.5. This is the output
from ldd:
ldd psycopg2/_psycopg.so
linux-gate.so.1 => (0xffffe000)
libpq.so.4 => /usr/lib/libpq.so.4 (0xb7f80000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7f6e000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e3d000)
libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7dfe000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7cc4000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7c48000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7c44000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7c16000)
/lib/ld-linux.so.2 (0x80000000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c12000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7bfe000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7bd9000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7bc5000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7bc0000)
Apache is the one packaged for debian etch (2.2.3-4+etch6), This is the
output from "apache2 -V":
Server version: Apache/2.2.3
Server built: Sep 6 2008 09:49:10
Server's Module Magic Number: 20051115:3
Server loaded: APR 1.2.7, APR-Util 1.2.7
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture: 32-bit
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT=""
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"
Neither mod_python or php modules are loaded, only the default ones
configured by a vanilla debian install (negotiation, alias, etc..) and
mod_svn (from debian etch too). I should note however that the problem
also manifested itself in another server without mod_svn being loaded.
Tell me if you need more information.
> Thanks.
>
Thanks to you Graham for mod_wsgi and your excellent support!
Alberto
[1]
http://toscawidgets.org/trac/twWebSite/browser/twwebsite/controllers/tracdelegate.py
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
