Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am running Apache httpd 2.4.4 on a RedHat 5 machine. I am using Django and running through mod_wsgi. I have Python 2.4.3 installed in /usr/bin and Python 2.7.6 installed in /usr/local/bin and I want to use 2.7.6. I build the 2.7.6 from source and also built mod_wsgi-3.4.

I have created a virtualenv using 2.7.6 and from a command shell, python -V tells me it's using 2.7.6 (after doing a . virtpy/bin/activate). Running import sys; sys.version shows me 2.7.6 as well, and sys.executable shows me /www/sqla/virtpy/bin/python.

When I run it from httpd, I get problems loading libraries and when I look at sys.version, I see 2.7.3. The weird thing is that sys.executable still shows me /www/sqla/virtpy/bin/python, exactly the same one as I see from the command shell.

Specifically, when python tries to load _socket, I see this error from httpd:

ImportError: /www/sqla/virtpy/lib/python2.7/lib-dynload/_socket.so: undefined symbol: _PyInt_AsInt

If I try to import _socket from a command shell, no problem. I have . /www/sqla/virtpy/bin/activate in my /etc/sysconfig/httpd and have restarted Apache with that change.

How can the same executable give different versions of python? How can I convince it to use the right one?

share|improve this question
    
Just to clarify, you built mod_wsgi in the virtualenv, using 2.7.6, correct? –  tfitzgerald Feb 6 at 22:01
    
@tfitzgerald Yes, I made sure of that. In fact I rebuilt it again (clean) just to make sure. –  Graeme Perrow Feb 7 at 0:15
    
Ok. What does your wsgi app / file look like? Might need to use site.addsitedir to point to the 2.7.6 site packages in your virtualenv. –  tfitzgerald Feb 7 at 2:28
    
But by the time my wsgi app is invoked, python is already running, and is using the wrong version. –  Graeme Perrow Feb 7 at 12:32

1 Answer 1

Use the checks documented in the mod_wsgi documentation to validate that how your mod_wsgi was compiled is correct:

Ensure that when doing this check that LD_LIBRARY_PATH is not set. Provide the output from ldd.

Also indicate whether you also have any Python 2.7 installation under /usr in addition to the one under /usr/local and specifically whether there is a Python 2.7 shared library under /usr/lib anywhere.

If you have used WSGIPythonHome directive in Apache configuration, say what you have set it to.

share|improve this answer
    
The ldd output for mod_wsgi.so includes "libpython2.7.so.1.0". If I run it with LD_LIBRARY_THREAD unset, it says "=> not found". The only libpython* under /usr/lib is /usr/lib/python2.4/config/libpython2.4.a. No WSGIPythonHome is set. –  Graeme Perrow Feb 7 at 0:46
    
But where is the libpython2.7.so it finds located? That it can't be found without LD_LIBRARY_PATH being set is not good and means you would have to be setting that in environment of Apache. You should really set LD_RUN_PATH at compile time so directory it is in is embedded in mod_wsgi.so so can find it. –  Graham Dumpleton Feb 7 at 10:50
    
OK, done. I did "LD_RUN_PATH=/usr/local/lib make" (clean) and "sudo make install". Doing an ldd on the resulting library (with LD_LIBRARY_PATH empty) shows "libpython2.7.so.1.0 => /usr/local/lib/libpython2.7.so.1.0 (0x00002b01f2199000)". But I still see the same result. (Note that in the comment above, I meant LD_LIBRARY_PATH, not LD_LIBRARY_THREAD). –  Graeme Perrow Feb 7 at 12:31
    
The only other thing can think of is that have seen this issue when the Python virtual environment was created off one Python patch level and then the main Python installation was upgraded without recreating the virtual environment. –  Graham Dumpleton Feb 8 at 1:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.