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'm new to Linux.

I'm managing a (Linux - Apache - mod_wsgi - Django) server, where there are multiple installations of Python. The site is currently working, but I want to find out which executable of Python is used to run it. I know it's not the default one.

Also, how does mod_wsgi know which installation of Python to use? The .wsgi script has no shebang line.

share|improve this question

5 Answers 5

up vote 4 down vote accepted

The #! line is not used and would not normally be placed into a WSGI script file as used by mod_wsgi.

To determine which version/installation of Python is used, there are two parts to it.

The first as pointed out by someone else is to work out which Python library mod_wsgi.so is linked to. On most UNIX systems this is done using the 'ldd' command.

ldd mod_wsgi.so

Run this on the actual mod_wsgi.so installed into the Apache modules directory which is being used. This will tell you for certain which version of mod_wsgi was compiled against.

If you do not see a reference to a libpythonX.Y.so file then your mod_wsgi.so was linked statically against Python library. Although this will work, so long as mod_python not also loaded into same Apache, it is a very bad idea to rely on it as use of static linking of Python library results in unnecessary bloating of your Apache processes due to runtime code relocation that has to be done when loading mod_wsgi.so with statically linked Python library.

Note that the value of 'sys.executable' when running under mod_wsgi has no meaning and cannot be used as a means of determining which Python version was used. This is because the command line Python is not used. Instead, the executable which is being run is actually Apache and sys.executable most likely will reflect that. It is only after Apache is run and the mod_wsgi.so loaded that Python is then initialised using embedded Python APIs. Similarly, running 'which python' will not help in determining exactly which installation of Python is being used.

The second part is working out what installation of Python was actually used at runtime. To do this you should use a WSGI hello world program and modify it to dump out the value of 'sys.prefix'. This tells you the root directory under which the Python installation is located. Based on what version of the Python shared library was used, you will then know which actual 'lib/pythonX.Y' directory under that root directory is being used. The version is important as there could well be multiple versions installed under that root directory.

Note that what you get for 'sys.prefix' may actually be different to the root directory as you thought it may be based on libpythonX.Y.so dependency of mod_wsgi.so file. This is because of the way that Python when initialised tries to find its 'lib' directory.

For example, if you had Python 2.6 installed under '/usr/local' and another one installed under '/usr', but you compiled mod_wsgi against that under '/usr/local', you may still find that 'sys.prefix' resolved to '/usr'. This is because by default in embedded systems Python looks at value of 'PATH' environment variable to get a search path to find a 'python' executable as base point for calculating the root directory, even though that 'python' executable was not used to start the process.

Under Apache, because it is usually started as 'root', it would not necessarily have '/usr/local/bin' in your 'PATH' and so would likely find '/usr/bin/python' instead and thus use '/usr' for 'sys.prefix'.

In this later sort of scenario where it finds a different root directory to what you want to use, one can use the WSGIPythonHome directive in Apache configuration to override what 'sys.prefix' is automatically calculated.

Note that you CANNOT use WSGIPythonHome to refer to a different version of Python, it must refer to a root directory containing a Python installation of the same major/minor version. If you need to use a different version of Python, you must recompile and reinstall mod_wsgi so it is compiled against the different version. The actual version/installation of Python to be used when compiling can be specified using the '--with-python' option to the mod_wsgi configure script when it is being built.

There are other ways besides using WSGIPythonHome directive to override which Python installation is used, but recommended you stick with WSGIPythonHome.

share|improve this answer

mod_wsgi is linked against a specific python version.

www:~# ls -l /usr/lib/apache2/modules/mod_wsgi*
lrwxrwxrwx 1 root root     15 2009-07-27 12:35 /usr/lib/apache2/modules/mod_wsgi.so -> mod_wsgi.so-2.5
-rw-r--r-- 1 root root 129552 2008-08-23 14:06 /usr/lib/apache2/modules/mod_wsgi.so-2.4
-rw-r--r-- 1 root root 129552 2008-08-23 14:06 /usr/lib/apache2/modules/mod_wsgi.so-2.5

alternatively you can do

www:~# ldd /usr/lib/apache2/modules/mod_wsgi.so
    ...
    libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb7de0000)
    ...
share|improve this answer
$ python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> 
>>> import sys
>>> 
>>> print sys.executable
/usr/bin/python
share|improve this answer

which python

That should show the python that is being picked up by the shell.

You'll want to run that as the apache user to have their $PATH set, rather that your users.

share|improve this answer

You can access sys.executable from within Python code to know what interpreter binary is used. Code a WSGI page to do it.

share|improve this answer
    
Whoever downvoted three answers silently: comments welcomed. –  Tobu Jan 31 '10 at 22:58
    
Read my really long post. It is easier to answer it properly in once place than start up multiple comment replies. –  Graham Dumpleton Jan 31 '10 at 23:25
    
The relevant part about sys.executable didn't jump out at me at first, but fair point. It would probably be the apache binary. –  Tobu Feb 1 '10 at 0:08

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.