How do I find the Python executable that my server is using?

6,458

Solution 1

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.

Solution 2

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)
    ...

Solution 3

$ 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:
6,458

Related videos on Youtube

Ram Rachum
Author by

Ram Rachum

Israeli Python developer.

Updated on September 17, 2022

Comments

  • Ram Rachum
    Ram Rachum over 1 year

    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.

  • user2910702
    user2910702 over 14 years
    Whoever downvoted three answers silently: comments welcomed.
  • Graham Dumpleton
    Graham Dumpleton over 14 years
    Read my really long post. It is easier to answer it properly in once place than start up multiple comment replies.
  • user2910702
    user2910702 over 14 years
    The relevant part about sys.executable didn't jump out at me at first, but fair point. It would probably be the apache binary.