Re: [modwsgi] WSGI unable to load Python modules when using virtualenv

[Graham Dumpleton]

This is usually caused by trying to make mod_wsgi use a Python virtual
environment based off a different Python version that mod_wsgi is
compiled for.

In other words, if mod_wsgi was originally compiled for Python 2.5,
you cannot force it to work against a Python virtual environment
created against Python 2.7.

The only choice is to reinstall mod_wsgi with version specifically
compiled against the target Python version.

So verify what version of Python mod_wsgi is compiled for:

http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Installation_In_Use

BTW, I would highly discourage putting your virtual environments under /usr/lib.

Graham

On 7 August 2012 10:52, quantoid <quan...@gmail.com> wrote:
> error_log:
>
> [Tue Aug 07 10:39:13 2012] [error] mod_wsgi (pid=28084): Unable to import
> 'site' module.
> [Tue Aug 07 10:39:13 2012] [error] [client 10.116.49.78] mod_wsgi
> (pid=28084): Target WSGI script
> '/var/lib/jenkins/jobs/Snoopy/workspace/main/src/snoopy/wsgi.py' cannot be
> loaded as Python module.
> [Tue Aug 07 10:39:13 2012] [error] [client 10.116.49.78] mod_wsgi
> (pid=28084): Exception occurred processing WSGI script
> '/var/lib/jenkins/jobs/Snoopy/workspace/main/src/snoopy/wsgi.py'.
> [Tue Aug 07 10:39:13 2012] [error] Traceback (most recent call last):
> [Tue Aug 07 10:39:13 2012] [error] File
> "/var/lib/jenkins/jobs/Snoopy/workspace/main/src/snoopy/wsgi.py", line 16,
> in <module>
> [Tue Aug 07 10:39:13 2012] [error] import os
> [Tue Aug 07 10:39:13 2012] [error] ImportError: No module named os
>
> httpd.conf:
>
> # Snoopy Applications
> WSGIScriptAlias /
> /var/lib/jenkins/jobs/Snoopy/workspace/main/src/snoopy/wsgi.py
> WSGIPythonHome /usr/lib/mypy
> WSGIPythonPath
> /usr/lib/mypy/lib/python2.7:/usr/lib/mypy/lib/python2.7/site-packages:/var/lib/jenkins/jobs/Snoopy/workspace/main/src
>
> <Directory /var/lib/jenkins/jobs/Snoopy/workspace/main/src/snoopy>
> Order deny,allow
> Allow from all
> </Directory>
>
> The virtualenv is at /usr/lib/mypy.
>
> All the files and directories listed in that configuration exist and have
> read permission for anyone (chmod a+r).
>
> I know similar problems have been posted here before but I've read those and
> the WSGI manual and still can't get it working. :(
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/modwsgi/-/MoY_vxuVIskJ.
> 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.

[quantoid]

Thanks for responding. I tried to rebuild against my new 2.7.3 installation but failed with "libpython2.7.a: could not read symbols: Bad value", which you've already pointed out elsewhere is because python has to be built with --enable-shared. I tried to rebuild python with that option but I get the same error there, which is because the makefile links against any existing python2.7 libraries in preference to the one it's rebuilding!

http://www.gossamer-threads.com/lists/python/python/862272

I temporarily renamed the existing libraries so that it links against the new one and was able to rebuild python 2.7 but now I get this error when building mod_wsgi:

/usr/lib/mypy/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

Is it looking for the python library in PREFIX/lib rather than my virtual environment? Specifying a different PREFIX probably won't work because it's only python that's not in a standard location.

What would be a good place to put a virtual environment, given the access restrictions on home directories effectively rule those out? I used /usr/lib because someone else had already installed python2.6 and a bunch of other things there.

What a chain-of-pain this has been! Thanks for your help though.

[quantoid]

By the way libpython2.7.so.1.0 definitely does now exist in my virtual environment and is readable (I'm building mod_wsgi with sudo).

[quantoid]

I've now upgraded the default python to the same version as the virtual environment (2.7.3) but building mod_wsgi still chucks the same error.

$ sudo ./configure --with-python=/usr/local/bin/python
checking for apxs2... no
checking for apxs... /usr/sbin/apxs
checking Apache version... 2.2.15
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
configure: creating ./config.status
config.status: creating Makefile
$ ls /usr/local/lib/libpy*
/usr/local/lib/libpython2.7.so  /usr/local/lib/libpython2.7.so.1.0

:(

[quantoid]

Finally fixed the build using symlink trick described under "Caveats" here:
http://cysec.org/content/compiling-modwsgi-custom-python-build

A couple of improvements to the makefile could save folks like me quite a bit of time:

1. Allow mod_wsgi to link against the static libpython.a rather than requiring a shared library.
2. Look for libraries in /usr/local/lib before /usr/lib or /usr/lib64.

[Graham Dumpleton]

On 10 August 2012 15:14, quantoid <quan...@gmail.com> wrote:
> Finally fixed the build using symlink trick described under "Caveats" here:
> http://cysec.org/content/compiling-modwsgi-custom-python-build
>
> A couple of improvements to the makefile could save folks like me quite a
> bit of time:
>
> 1. Allow mod_wsgi to link against the static libpython.a rather than
> requiring a shared library.

Do not do that. Linking in the static library is bad for other reasons
including processes using a lot more memory.

http://code.google.com/p/modwsgi/wiki/InstallationIssues#Lack_Of_Python_Shared_Library

> 2. Look for libraries in /usr/local/lib before /usr/lib or /usr/lib64.

Run mod_wsgi build as:

LD_RUN_PATH=/usr/local/lib make

That is set LD_RUN_PATH to directory where Python library is
installed. That will force reference to it.

http://code.google.com/p/modwsgi/wiki/InstallationIssues#Unable_To_Find_Python_Shared_Library

Test that correct library being used:

http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library

Graham