On Nov 4, 9:39 am, "Graham Dumpleton" <[EMAIL PROTECTED]>
wrote:
> 2008/11/4 Martijn Pieters <[EMAIL PROTECTED]>:
> > We are attempting to run mod_wsgi 2.3 on Apache 2.2.4 with python
> > 2.4.4 hand-compiled into a separate directory. Configuration for each:
>
> What operating system are you using?
>
> If you are on Linux, do you have SELinux extensions enabled?
Linux (Debian etch), no SELinux
> > Python: $ ./configure --prefix=/opt/python244 --enable-shared
> > Apache: $ ./configure --with-mpm=worker --prefix=/opt/apache --
> > enable-proxy --enable-proxy-http --enable-ssl --enable-http --enable-
> > dav --enable-suexec --enable-rewrite --enable-cache --enable-disk-
> > cache --enable-so --enable-cgi --enable-deflate --with-suexec-docroot=/
> > home/
> > mod_wsgi: $ LDFLAGS="-Wl,-R/opt/python244/lib" ./configure --with-
> > python=/opt/python244/bin/python --with-apxs=/opt/apache/bin/apxs
>
> > In mod_wsgi's case, the LDFLAGS environment parameter was ignored and
> > I hand-edited the Makefile to put this back in:
>
> > LDFLAGS = -Wl,-R/opt/python244/lib/ -L/opt/python244/lib/python2.4/
> > config
>
> > The module was correctly linked against the /opt/python244/lib/
> > libpython2.4.so.1.0 library.
>
> > I have been unable to get our WSGI setup working though, as mod_wsgi
> > segfaults every time. The apache server also has mod_python available,
> > but even when I disable loading the mod_python module the segfaults
> > occur. Our mod_wsgi configuration:
>
> Did you do a full stop of Apache after having disabled mod_python?
Yes, apachectl stop until apache reports it is no longer running.
> Is the process crash occurring at startup, or upon first request to
> server for Trac?
First request.
> > General config:
> > <IfModule mod_wsgi>
> > WSGIPythonHome /opt/python244
> > </IfModule>
>
> Do you have another Python installation on the system somewhere? If
> not, you possibly shouldn't need this.
The debian python2.4 package is also installed, so /opt/python244 is
not the only python on the system.
> > Virtual host specific config:
>
> > WSGIDaemonProcess trac-jarn user=psol group=psol threads=25
>
> Have you tried a hello world program without create a mod_wsgi daemon
> process, ie., run it in embedded mode. In other words, does mod_wsgi
> work at all or does it only have problems for Trac?
I just tried the simplest hello world app from PEP 333 and it works.
Hrm.
> > WSGIScriptAlias / [....]/trac.wsgi
> > WSGICallableObject trac.web.main.dispatch_request
>
> You can't have a dotted path as WSGICallableObject. Can only refer to
> objects at global scope in the file/module.
The object is available at the global scope; in other words,
trac.web.main.dispatch_request is directly accessible at the global
scope. No matter, it's easy enough to add the line:
def application(*args): return trac.web.main.dispatch_request(*args)
Removing WSGICallableObject and adding that line does not alter the
outcome however.
> > <Directory [...]>
> > WSGIProcessGroup trac-jarn
> > WSGIApplicationGroup %{GROUP}
>
> > Order deny,allow
> > Allow from all
> > AuthType Basic
> > AuthName "Trac"
> > AuthUserFile [....]
> > Require valid-user
> > </Directory>
>
> > I've experimented with various setups where WSGICallableObject is not
> > needed (so the script provides an application callable) but to no
> > effect.
>
> > With loglevel info, I get the following output:
>
> > [Tue Nov 04 08:29:49 2008] [notice] Apache/2.2.4 (Unix) mod_ssl/2.2.4
> > OpenSSL/0.9.8c DAV/2 SVN/1.4.3 PHP/5.2.6 mod_wsgi/2.3 Python/2
> > .4.4 configured -- resuming normal operations
>
> Does it work if PHP has been disabled from Apache?
No.
> Have you ensure that Python was compiled against same expat and SSL
> libraries as Apache and PHP?
Yes, the standard debian etch packages were used here.
> What database are you using for Trac? Does PHP installation also
> support that database? If it does, do they use compatible database
> client libraries?
sqlite; again the Debian packages were used so the PHP installation
(if at all) uses the same libraries.
> These issues and others covered in:
>
> http://code.google.com/p/modwsgi/wiki/InstallationIssues
> http://code.google.com/p/modwsgi/wiki/ApplicationIssues
And excellent documentation that is too.
I also tried to add logging lines, but that would also cause the
segfault:
import logging
logging.basicConfig(filename='/tmp/wsgi.log')
logging.info('Loaded trac.wsgi')
def application(environ, start_response):
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['Hello world!\n']
logging.info('Imported trac.web.main')
logging.close()
Interestingly enough, removing the logging.close() line let's the
above code work again.
Martijn Pieters
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
