500 error on import of import django.core.handlers.wsgi
John Blaze
I have run this handler fine, but if I import wsgi (from
django.core.handlers import wsgi) or (from django.core.handlers.wsgi
import WSGIHandler) I get a 500 error. I am using OS X 10.6.2, apache
2.2.*, python 2.6.4, django-1.1.1 and django-svn (for testing)
This error happens on both mod_wsgi 2.6 and 3.1 - I
Help me please.
Thanks,
J
-----
import os, sys
# adding project paths
sys.path.append('/usr/local/www/')
sys.path.append('/usr/local/www/theirry/')
sys.path.append('/usr/ports/Library/Frameworks/Python.framework/
Versions/2.6/lib/python2.6/site-packages/django')
from django.core import handlers
#application = handlers.wsgi.WSGIHandler()
sys.stdout = sys.stderr
def application(environ, start_response):
status = '200 OK'
output = 'Hello World!'
output += '\n'.join(sys.path)
output += '\n%s' % dir(handlers.wsgi)
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
Graham Dumpleton
Python traceback?
What do you get when you run:
otool -L mod_wsgi.so
My guess is that since you are using MacPorts, you are hitting issue
with MacPorts Python where it doesn't resolve proper version of Python
framework at run time. That you are even trying to do:
sys.path.append('/usr/ports/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django')
suggests that perhaps.
First off the line is wrong because if things are working correctly
then it would look in site-packages already.
Second, mixing stuff from Python installations like that is not a good idea.
Third it is wrong because you wouldn't need 'django' at the end in
circumstances where this was valid such as when using virtual
environments.
Anyway, if otool shows wrong framework being picked up, rebuild
mod_wsgi and when you run configure add the additional option:
--disable-framework
This will hopefully work around the problems in MacPorts Python. You
should use mod_wsgi 3.1 however for this option, not sure it is in
mod_wsgi 2.6.
Preferably, don't use MacPorts Python at all, it is a never ending
source of problems when embedding and where Apache is running as 64
bits.
Graham
2009/12/11 John Blaze <j.st...@gmail.com>:
>
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>
>
John Blaze
use Frameworks and it finally works.
On Dec 10, 9:27 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> Python traceback?
>
> What do you get when you run:
>
> otool -L mod_wsgi.so
>
> My guess is that since you are using MacPorts, you are hitting issue
> with MacPorts Python where it doesn't resolve proper version of Python
> framework at run time. That you are even trying to do:
>
> suggests that perhaps.
>
> First off the line is wrong because if things are working correctly
> then it would look in site-packages already.
>
> Second, mixing stuff from Python installations like that is not a good idea.
>
> Third it is wrong because you wouldn't need 'django' at the end in
> circumstances where this was valid such as when using virtual
> environments.
>
> Anyway, if otool shows wrong framework being picked up, rebuild
> mod_wsgi and when you run configure add the additional option:
>
> --disable-framework
>
> This will hopefully work around the problems in MacPorts Python. You
> should use mod_wsgi 3.1 however for this option, not sure it is in
> mod_wsgi 2.6.
>
> Preferably, don't use MacPorts Python at all, it is a never ending
> source of problems when embedding and where Apache is running as 64
> bits.
>
> Graham
>
Valery
On Dec 11, 5:53 pm, John Blaze <j.sta...@gmail.com> wrote:
> Thanks Graham - I install a custom version of python which does not
> use Frameworks and it finally works.
how did you install this Frameworks-free version?
we're experiencing exactly the same issue here...
regards
Valery
Graham Dumpleton
Not sure it is correct to say it is a framework free version of
Python. There is still a framework but don't use -F/-framework options
to link with it, but instead use -L/-l instead. See bug fix 2 in:
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0206
In other words, use --disable-framework option to configure for
mod_wsgi as described in prior post in this discussion.
So, perhaps poor way of describing what was done.
But then, he may well have installed a .dylib version of Python as is
it possible. I have though never explicitly tested with that type of
Python installation that I recollect.
Graham
> regards
> Valery
Valery
> Preferably, don't use MacPorts Python at all, it is a never ending
> source of problems when embedding and where Apache is running as 64
> bits.
wow. And what Python installation would you recommend?
"download sources, configure, make, make install" ? -- if yes, any
additional options for ./configure ?
isn't this way dangerous? -- "make install" is blind and could
overwrite Python instance(s) vital for the OS. Plus, deinstallation
becomes tricky.
regards
Valery
Graham Dumpleton
No worse than MacPorts really. MacPorts often pollutes /Library which is a PITA.
As documented in:
http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
Use original PSF source code with:
./configure --prefix=/usr/local/python-2.5.4 \
--enable-framework=/usr/local/python-2.5.4/frameworks \
--enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 \
--with-universal-archs=all
Amend Python version depending on what you are using.
With that, installed under /usr/local/python-X.Y.Z, with a bit of
stuff under '/Applications/Python\ X.Y' so relativey easy to remove
later.
Graham
Valery
according to http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
the precompiled version from PSF has been installed.
Snow Leopard 10.6. is used here with the apache 2.2.14 preforkmpm from
MacPorts.
Now, the recent mod_wsgi 3.1 sources are downloaded, configured via
plain ./configure, no command line options.
If no changes are made to Makefile, then:
LIBEXECDIR = /usr/libexec/apache2
it is, perhaps, for Snow Leopard's WebSharing apache (btw, maybe it
would be also a good way to go?)
We are with apache from MacPorts, so we are changing LIBEXECDIR to /
opt/local/apache2/modules/ , so that /opt/local/apache2/modules/
mod_wsgi.so is created instead of /usr/libexec/apache2/mod_wsgi.so
Now when we start apache with apachectl -k start and the following
error appears immeditelly in console:
httpd: Syntax error on line 483 of /opt/local/apache2/conf/httpd.conf:
Syntax error on line 1 of /Users/user/Work/django-src/apache/httpd-
macos-django.conf: Cannot load /opt/local/apache2/modules/mod_wsgi.so
into server: dlopen(/opt/local/apache2/modules/mod_wsgi.so, 10):
Symbol not found: _PyBool_Type\n Referenced from: /opt/local/apache2/
modules/mod_wsgi.so\n Expected in: flat namespace\n in /opt/local/
apache2/modules/mod_wsgi.so
The change to LDFLAGS mentioned in http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
was applied -- the same outcome.
Another error variant that happens during apache start is:
httpd: Syntax error on line 483 of /opt/local/apache2/conf/httpd.conf:
Syntax error on line 1 of /Users/bogdan/Work/django-src/apache/httpd-
macos-django.conf: Cannot load /opt/local/apache2/modules/mod_wsgi.so
into server: dlopen(/opt/local/apache2/modules/mod_wsgi.so, 10):
Symbol not found: _apr_file_info_get$INODE64\n Referenced from: /opt/
local/apache2/modules/mod_wsgi.so\n Expected in: flat namespace\n in /
opt/local/apache2/modules/mod_wsgi.so
Last but not least, "make install" meantions:
libtool: install: warning: remember to run `libtool --finish /usr/
libexec/apache2'
whereas libtool --finish isn't supported on Snow Leopard.
Hints are very appreciated!
regards,
Valery
Graham Dumpleton
> Hi Graham,
>
> according to http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
> the precompiled version from PSF has been installed.
Huh? You mean you installed the precompiled version from PSF from dmg
file even though that documentation says it is not a universal
install? Or do you mean you installed from source code from PSF source
code rather than MacPorts?
> Snow Leopard 10.6. is used here with the apache 2.2.14 preforkmpm from
> MacPorts.
>
> Now, the recent mod_wsgi 3.1 sources are downloaded, configured via
> plain ./configure, no command line options.
Why no command line options?
Since you now seem to have multiple Python/Apache installations, may
be unpredictable as to which actually gets used depending on how you
have PATH set.
> If no changes are made to Makefile, then:
>
> LIBEXECDIR = /usr/libexec/apache2
>
> it is, perhaps, for Snow Leopard's WebSharing apache (btw, maybe it
> would be also a good way to go?)
>
> We are with apache from MacPorts, so we are changing LIBEXECDIR to /
> opt/local/apache2/modules/ , so that /opt/local/apache2/modules/
> mod_wsgi.so is created instead of /usr/libexec/apache2/mod_wsgi.so
What is wrong with using the '--with-apxs' option to the mod_wsgi
'configure' script?
See:
http://code.google.com/p/modwsgi/wiki/QuickInstallationGuide
> Now when we start apache with apachectl -k start and the following
> error appears immeditelly in console:
>
> httpd: Syntax error on line 483 of /opt/local/apache2/conf/httpd.conf:
> Syntax error on line 1 of /Users/user/Work/django-src/apache/httpd-
> macos-django.conf: Cannot load /opt/local/apache2/modules/mod_wsgi.so
> into server: dlopen(/opt/local/apache2/modules/mod_wsgi.so, 10):
> Symbol not found: _PyBool_Type\n Referenced from: /opt/local/apache2/
> modules/mod_wsgi.so\n Expected in: flat namespace\n in /opt/local/
> apache2/modules/mod_wsgi.so
>
> The change to LDFLAGS mentioned in http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
> was applied -- the same outcome.
What changes?
You don't need to make any such changes with mod_wsgi 3.1.
My fault in part there as documentation there isn't necessarily
completely up to date.
There are two options, you either don't supply --disable-framework to
configure, or you do.
If neither of those works with the Python installation you are using,
the short answer is you will not be able to use that Python
installation because it is unsuitable for embedding due to something
wrong in the Python installation. That or the Python installation
isn't fat.
> Another error variant that happens during apache start is:
>
> httpd: Syntax error on line 483 of /opt/local/apache2/conf/httpd.conf:
> Syntax error on line 1 of /Users/bogdan/Work/django-src/apache/httpd-
> macos-django.conf: Cannot load /opt/local/apache2/modules/mod_wsgi.so
> into server: dlopen(/opt/local/apache2/modules/mod_wsgi.so, 10):
> Symbol not found: _apr_file_info_get$INODE64\n Referenced from: /opt/
> local/apache2/modules/mod_wsgi.so\n Expected in: flat namespace\n in /
> opt/local/apache2/modules/mod_wsgi.so
Likely because you compiled against header files from one Apache
installation and then tried to use the compiled module with another
Apache installation which has different APR dependencies or compile
options.
> Last but not least, "make install" meantions:
>
> libtool: install: warning: remember to run `libtool --finish /usr/
> libexec/apache2'
>
> whereas libtool --finish isn't supported on Snow Leopard.
>
> Hints are very appreciated!
Be clearer about what Python you are using and how it was installed.
Use the --with-python and --with-apxs options to 'configure' as
documented so as to be precise about what installations you are using.
Do not go modify the generated Makefile by hand. The configure script
will do the correct things if you supply correct options to it.
If not supplying --disable-framework doesn't work then try supplying
it. If that still doesn't work and you didn't get Apache bits wrong,
then that Python installation you are using is stuffed and can't be
used for embedding.
Overall I would simply suggest you use Python/Apache supplied by
Apple. They work. So, take MacPorts or other Python/Apache
installations out of your PATH and start over with a 'make distclean'
and then 'configure'. Validate that not still compiling against non
Apple installations.
Graham
Valery
> file even though that documentation says it is not a universal
> install?
exactly.
And actually I didn't see any statements:
* neither on PSF if dmg is universal or not
* nor at http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
if it needs universal or not...
Sorry, if I missed something,
Valery.
Graham Dumpleton
Documentation says:
"""Non Universal MacPython
The Python Software Foundation provides a precompiled Python
distribution for MacOS X referred to as MacPython. The Python
framework this contains does not however support 64 bit architectures.
This means that although mod_wsgi may be configured and built for 64
bit architectures where Apache being used supports it, a run time
failure will occur when Apache is started."""
I presume you will get back to me when you have tried the other things.
Graham
> Sorry, if I missed something,
>
> Valery.
>
>
>
Valery Khamenya
first of all let me thank you for the great support you make for the
mod_wsgi users.
In fact, we fail to get mod_wsgi running under Snow Leopard.
And I want to emphasize that this has nothing to do neither with
mod_wsgi nor with the job you do around it -- it is great and myself,
as a happy user of your work, am continuing to use mod_wsgi under
Linux.
Why it still fails under Snow Leo? -- Here it is:
1. the following
./configure --prefix=/usr/local/python-2.6.4 \
--enable-framework=/usr/local/python-2.6.4/frameworks \
--enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6 \
--with-universal-archs=all
exits with error. Namely configure script fails to determine wchat_t
size. Similar to this:
http://mail.python.org/pipermail/python-bugs-list/2005-January/027202.html
If --enable-universalsdk=/ is changed from System libraries to 10.6
SDK (--enable-universalsdk) then the configure script runs through
with the tones of warnings. The failure happens during the make phase.
2. MacPorts' apache has a universal variant. Its compilation also
fails because of missing or corrupt SSL/TSL, similar to
http://trac.macports.org/ticket/19996
I think it makes sense to wait until MacPorts come closer to
mod_wsgi's requirements.
Well, finally we moved to Ubuntu Server 9.10 and with *no* problems at
all got mod_wsgi running.
best regards
--
Valery
Graham Dumpleton
> Hi Graham,
>
> first of all let me thank you for the great support you make for the
> mod_wsgi users.
>
> In fact, we fail to get mod_wsgi running under Snow Leopard.
> And I want to emphasize that this has nothing to do neither with
> mod_wsgi nor with the job you do around it -- it is great and myself,
> as a happy user of your work, am continuing to use mod_wsgi under
> Linux.
>
> Why it still fails under Snow Leo? -- Here it is:
>
> 1. the following
>
> ./configure --prefix=/usr/local/python-2.6.4 \
> --enable-framework=/usr/local/python-2.6.4/frameworks \
> --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6 \
> --with-universal-archs=all
We sorted this out in a separate parallel thread. Use following for Python.
./configure --prefix=/usr/local/python-2.6.4
--enable-framework=/usr/local/python-2.6.4/frameworks
--enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5
--with-universal-archs=3-way
Then for mod_wsgi.
./configure --with-python=/usr/local/python-2.6.4/bin/python
This should result in:
Archimedes:mod_wsgi-3.1 awolf$ otool -L /opt/apache2/modules/
mod_wsgi.so
/opt/apache2/modules/mod_wsgi.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.0.0)
/usr/local/python-2.6.4/frameworks/Python.framework/Versions/2.6/
Python (compatibility version 2.6.0, current version 2.6.0)
Graham
> exits with error. Namely configure script fails to determine wchat_t
> size. Similar to this:
> http://mail.python.org/pipermail/python-bugs-list/2005-January/027202.html
>
> If --enable-universalsdk=/ is changed from System libraries to 10.6
> SDK (--enable-universalsdk) then the configure script runs through
> with the tones of warnings. The failure happens during the make phase.
>
> 2. MacPorts' apache has a universal variant. Its compilation also
> fails because of missing or corrupt SSL/TSL, similar to
> http://trac.macports.org/ticket/19996
>
> I think it makes sense to wait until MacPorts come closer to
> mod_wsgi's requirements.
>
> Well, finally we moved to Ubuntu Server 9.10 and with *no* problems at
> all got mod_wsgi running.
>
> best regards
> --
> Valery
>
Valery Khamenya
thank you for your answer,
On Thu, Dec 24, 2009 at 10:23 AM, Graham Dumpleton
<graham.d...@gmail.com> wrote:
> ./configure --prefix=/usr/local/python-2.6.4
> --enable-framework=/usr/local/python-2.6.4/frameworks
> --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5
> --with-universal-archs=3-way
is MACOSX_DEPLOYMENT_TARGET=10.5 intended ?
10.6 sounds more natural for me.
best regards
--
Valery A.Khamenya
Graham Dumpleton
As stated in other discussion, that variable indicates oldest version
of MacOS X to be supported by the install. So, if you only care about
10.6, then fine use that. There is no harm in using 10.5 though on a
10.6 system. All it means is that technically you could take that
installation as is and still run it on a 10.5 system and should still
work.
Graham
> best regards
> --
> Valery A.Khamenya
>