Passing LD_PRELOAD to apache 2.4 for mod_wsgi

Question

I can't adapt this question for mod_wsgi.

I have a python flask application that uses gdal. I start it up the following way:

LD_PRELOAD=/opt/gdal-custom/lib/libgdal.so.1 PYTHONPATH=../somemodules/ scl enable python27 "source ../python27/bin/activate; python flaskapp.py"

However, I'd like to host it in mod_wsgi. Doing LD_PRELOAD=/opt/gdal-custom/lib/libgdal.so.1 service httpd24-httpd restart doesn't seem to work. Neither does setting the following in my apache configuration:

SetEnv LD_PRELOAD /opt/gdal-custom/lib/libgdal.so.1

LoadModule wsgi_module modules/mod_wsgi.so

WSGIPythonHome /opt/rh/httpd24/root/var/www/wsgi-virtualenv

WSGIPythonPath /opt/rh/httpd24/root/var/www/AppFolder:/opt/rh/httpd24/root/var/www/SomeModules

WSGIScriptAlias /AppFolder /opt/rh/httpd24/root/var/www/AppFolder/app.wsgi

<Directory /var/www/AppFolder>
AllowOverride none
Require all granted
</Directory>

Here is the output of ldd:

(wsgi-virtualenv)ldd /opt/rh/httpd24/root/var/www/wsgi-virtualenv/lib/python2.7/site-packages/GDAL-1.11.2-py2.7-linux-x86_64.egg/osgeo/_gdal.so
    linux-vdso.so.1 =>  (0x00007fffac9ff000)
    libpython2.7.so.1.0 => /opt/rh/python27/root/usr/lib64/libpython2.7.so.1.0 (0x00007fce43438000)
    libgdal.so.1 => /opt/gdal-custom/lib/libgdal.so.1 (0x00007fce42490000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fce42176000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fce41ef2000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fce41cdb000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fce41abe000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fce4172a000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fce41525000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00007fce41322000)
    libfreexl.so.1 => /usr/lib64/libfreexl.so.1 (0x00007fce41119000)
    libgeos_c.so.1 => /usr/lib64/libgeos_c.so.1 (0x00007fce40ef2000)
    libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007fce40c63000)
    libodbc.so.2 => /usr/lib64/libodbc.so.2 (0x00007fce409fc000)
    libodbcinst.so.2 => /usr/lib64/libodbcinst.so.2 (0x00007fce407ea000)
    libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fce405c2000)
    libxerces-c-3.0.so => /usr/lib64/libxerces-c-3.0.so (0x00007fce40021000)
    libjasper.so.1 => /usr/lib64/libjasper.so.1 (0x00007fce3fdc7000)
    libnetcdf.so.6 => /usr/lib64/libnetcdf.so.6 (0x00007fce3fa82000)
    libhdf5.so.6 => /usr/lib64/libhdf5.so.6 (0x00007fce3f49a000)
    libogdi.so.3 => /usr/lib64/libogdi.so.3 (0x00007fce3f278000)
    libgif.so.4 => /usr/lib64/libgif.so.4 (0x00007fce3f06f000)
    libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fce3ee1f000)
    libgta.so.0 => /usr/lib64/libgta.so.0 (0x00007fce3ec14000)
    libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fce3e9ee000)
    libcfitsio.so.0 => /usr/lib64/libcfitsio.so.0 (0x00007fce3e63a000)
    libpq.so.5 => /usr/lib64/libpq.so.5 (0x00007fce3e411000)
    librt.so.1 => /lib64/librt.so.1 (0x00007fce3e209000)
    libpcre.so.0 => /lib64/libpcre.so.0 (0x00007fce3dfdd000)
    libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007fce3dd88000)
    libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007fce3da35000)
    libz.so.1 => /lib64/libz.so.1 (0x00007fce3d81f000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003e73a00000)
    libgeos-3.4.2.so => /usr/lib64/libgeos-3.4.2.so (0x00007fce3d479000)
    libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007fce3d270000)
    libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fce3d056000)
    libhdf5_hl.so.6 => /usr/lib64/libhdf5_hl.so.6 (0x00007fce3ce24000)
    libproj.so.0 => /usr/lib64/libproj.so.0 (0x00007fce3cbd7000)
    libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007fce3c9ce000)
    libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007fce3c7b2000)
    libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fce3c475000)
    liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x00007fce3c253000)
    libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fce3c042000)
    libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007fce3bdd6000)
    libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007fce3b9f2000)
    libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fce3b7ae000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fce3b577000)
    libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007fce3b31e000)
    libidn.so.11 => /lib64/libidn.so.11 (0x00007fce3b0ec000)
    libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fce3ae9c000)
    libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fce3abb5000)
    libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fce3a989000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fce3a785000)
    libssl3.so => /usr/lib64/libssl3.so (0x00007fce3a545000)
    libsmime3.so => /usr/lib64/libsmime3.so (0x00007fce3a319000)
    libnss3.so => /usr/lib64/libnss3.so (0x00007fce39fda000)
    libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007fce39dad000)
    libplds4.so => /lib64/libplds4.so (0x00007fce39ba9000)
    libplc4.so => /lib64/libplc4.so (0x00007fce399a4000)
    libnspr4.so => /lib64/libnspr4.so (0x00007fce39765000)
    libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x00007fce3953d000)
    libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fce39338000)
    libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fce3911a000)
    libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fce38f0e000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fce38d0b000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fce38af1000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007fce388ed000)
    liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007fce386de000)
    libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007fce384c4000)
    libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fce382c0000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fce380a1000)

score 1 · Answer 1 · answered Jun 16 '15 at 20:42

1

Why are you using LD_PRELOAD specifically?

Normally if you have a Python module or application which links a shared library which isn't in a standard directory on the system library search path you would use LD_LIBRARY_PATH.

Using LD_LIBRARY_PATH will still not help with the way you are doing it as either has to be set in the environment before the application process is started. The SetEnv directory doesn't do that for mod_wsgi.

What you would normally do to get around this problem is to set a different environment variable again, called LD_RUN_PATH, but set it at the time you are compiling the Python module, application or library which requires it.

Thus, when installing the Python module requiring it, do:

LD_RUN_PATH=/opt/gdal-custom/lib pip install somemodule

answered Jun 16 '15 at 20:42

Graham Dumpleton

5,990
2
20
19

Ok I rebuilt the module with LD_RUN_PATH during the build and install stages of setup.py, but after a `service httpd24-httpd restart` I get the same issue in the apache log: ` ImportError: /opt/rh/httpd24/root/var/www/wsgi-virtualenv/lib/python2.7/site-packages/GDAL-1.11.2-py2.7-linux-x86_64.egg/osgeo/_gdal.so: undefined symbol: GDALRasterBandGetVirtualMem` – Justin Dearing Jun 16 '15 at 21:16
What do you get when you run ``ldd /opt/rh/httpd24/root/var/www/wsgi-virtualenv/lib/python2.7/site-packages/GDAL-1.‌11.2-py2.7-linux-x86_64.egg/osgeo/_gdal.so``. Add the result to your question. That command will show you what libraries are linked to the module and where it is finding them. Make sure you do not have ``LD_LIBRARY_PATH`` set to include the library directory when you do it else it will not show whether library being resolved all by itself. – Graham Dumpleton Jun 16 '15 at 22:51
I added the output. had to slightly change the command – Justin Dearing Jun 23 '15 at 15:53
What do you get if you run ``nm /opt/gdal-custom/lib/libgdal.so.1 | grep GDALRasterBandGetVirtualMem``? – Graham Dumpleton Jun 23 '15 at 22:55
Its definitely exported 00000000006742d0 T GDALRasterBandGetVirtualMem – Justin Dearing Jun 24 '15 at 13:42
Are you loading mod_php into the same Apache? If mod_php was also loading that library somehow through an extension, but loading a different version, then that other version may not be compatible. This would explain why preloading works as it would override it. – Graham Dumpleton Jun 24 '15 at 20:39
1

Maybe what you can do is without attempting to load the Python application, run ``pldd`` on the process ID of the Apache process to see what libraries it already has linked. – Graham Dumpleton Jun 24 '15 at 20:40
1

I'm not running PHP. I am running [mod_R](https://github.com/jeffreyhorner/rapache), which is R for apache, and I do some geospatial stuff there.. I'll try pldd. – Justin Dearing Jun 24 '15 at 21:30
Ok it was rgdal. I can't seem to upgrade that, but I don't actually need rgdal in my rapache setup. Change your comment to an answer and I'll accept it. Thanks a lot! – Justin Dearing Jun 25 '15 at 12:46

Passing LD_PRELOAD to apache 2.4 for mod_wsgi

1 Answers1