mod_wsgi: CentOS - Cannot load /etc/httpd/modules/mod_wsgi.so into server: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory

(venv-3.5)[me@server new_folder]$ sudo service httpd restart
Starting httpd: [Mon Nov 02 20:29:33 2015] [warn] module php5_module is already loaded, skipping
httpd: Syntax error on line 222 of /etc/httpd/conf/httpd.conf: 
Syntax error on line 1 of /etc/httpd/conf.d/wsgi.conf:
Cannot load /etc/httpd/modules/mod_wsgi.so into server:
libpython3.5m.so.1.0: cannot open shared object file:
No such file or directory
[FAILED]

Apache:

Server MPM:     Prefork
Server version: Apache/2.2.15 (Unix)

[me@server ~]$  cat /etc/httpd/conf.d/wsgi.conf
LoadModule wsgi_module modules/mod_wsgi.so
[me@server ~]$

How I installed the components:

Python Install

[me@server Python-3.5.0]$ ./configure --prefix=/usr/local --enable-shared --with-threads
[me@server Python-3.5.0]$ make && make altinstall

mod_wsgi Install

[me@server mod_wsgi]$ ./configure --with-python=/usr/local/bin/python3.5
[me@server mod_wsgi]$ make
[me@server mod_wsgi]$ sudo make install

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 22 (9 by maintainers)

Most upvoted comments

Okay, total brain fade on my part. Yes, meant ldconfig -p.

What that shows is that likely /usr/local/lib is not listed in /etc/ld.so.conf as a directory that will be searched for shared libraries.

My understanding is that Linux systems would usually look there, so not sure why it isn’t.

The simplest thing to do therefore is go back to the mod_wsgi source code and do:

make distclean
./configure --with-python=/usr/local/bin/python3.5
LD_RUN_PATH=/usr/local/lib make
sudo make install

+11

GrahamDumpleton on Nov 3, 2015

I got it working with python 3.4. Thank you soooooooo much for all your help.

For future reverence, if someone is curious, here is a log of what I did:

cd ~
PY_VERSION="3.4.3"

######
# Download Python
#
mkdir software
cd software
wget http://www.python.org/ftp/python/$PY_VERSION/Python-$PY_VERSION.tgz -O Python-$PY_VERSION.tgz
gunzip -c Python-$PY_VERSION.tgz | tar xvf -
cd Python-$PY_VERSION/

######
# Python install
#
make clean
./configure --prefix=/usr/local --enable-shared LDFLAGS="-Wl,--rpath=/usr/local/lib"
make && sudo make altinstall

######
# mod_wsgi install
#
# got it from stable download section of github
cd ../mod_wsgi/
make distclean
./configure --with-python=/usr/local/bin/python3.4
#make with custom path
LD_RUN_PATH=/usr/local/lib make
sudo make install

######
# Virtualenv
#
cd  /var/www-django/django-project/
sudo /usr/local/bin/pip3.4 install virtualenv
virtualenv-3.4 venv-3.4
source venv-3.4/bin/activate
pip install mod_wsgi
# in django project path
python setup.py install


######
# Run it.
#
python manage.py runmodwsgi --port 8080
# or
sudo /var/www-django/django-project/venv-3.4/bin/python manage.py runmodwsgi --port 80 --user=apache --group=apache

luckydonald on Aug 8, 2018

This is because the shared library for Python isn’t being found at run time. That you are installing in /usr/local should mean though that it would be in /usr/local/lib and generally that directory is in the default directory search path used for shared libraries, although there is a possibility that CentOS doesn’t actually look there, or your system is setup with a SELinux profile which is prohibiting Apache from using shared libraries from that directory.

A few things you can do.

First is to make sure whether the Python shared library is actually in /usr/local/lib.

Second is to see whether even as a normal user you can resolve the library correctly by running:

ldd /etc/httpd/modules/mod_wsgi.so

and see what it says. Post the output.

Next is to see what directories the dynamic linker is even looking in by running:

ldcache -p

and see what it says. Post the output.

Finally, if necessary one could rebuild mod_wsgi from clean source code, but this time set LD_RUN_PATH environment variable, during compilation only, with it being set to the directory that the Python shared library actually lives in. This way mod_wsgi should be able to find it later when Apache is started.

As to python manage.py runmodwsgi, it is running Apache/mod_wsgi and not the Django development server. It still provides all the security and stability of Apache and so know of no reason it cannot be used in production. That management command is actually just a convenience command for running mod_wsgi-express and it gets used in production.

GrahamDumpleton on Nov 2, 2015