1

I'm stuck on a case where the MySQL libraries won't be found on a Apache/mod_wsgi/Django deployed server, altough Python alone can import the library correctly.

Here's my Apache log errors:

[Tue Jul 10 12:52:02 2012] [error] [client 127.0.0.1]   File "/remote/projects1/pdrtke/python/lib/python2.6/site-packages/Django-1.3-py2.6.egg/django/utils/importlib.py", line 35, in import_module
[Tue Jul 10 12:52:02 2012] [error] [client 127.0.0.1]     __import__(name)
[Tue Jul 10 12:52:02 2012] [error] [client 127.0.0.1]   File "/remote/projects1/pdrtke/python/lib/python2.6/site-packages/Django-1.3-py2.6.egg/django/db/backends/mysql/base.py", line 14, in <module>
[Tue Jul 10 12:52:02 2012] [error] [client 127.0.0.1]     raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
[Tue Jul 10 12:52:02 2012] [error] [client 127.0.0.1] ImproperlyConfigured: Error loading MySQLdb module: libmysqlclient_r.so.16: cannot open shared object file: No such file or directory

I already tried the following:

  • Check that Python interpreter can do import MySQLdb : Ok
  • Check that python manage.py ... actions requiring database support work: Ok
  • Check that LD_LIBRARY_PATH points to a directory where libmysqlclient_r.so.16 is available : Ok
  • Attach the httpd process with gdb, and do a show env : The LD_LIBRARY_PATH points to libmysqlclient_r.so.16 too
  • Modify the envvars file in the bin/http directory to add an export LD_LIBRARY_PATH=... (just in case): Ok
  • Check by a ldd libmysqlclient_r.so.16 that the library itself does not contain unresolved dependencies
  • Check that the httpd executable does not have the setuid bit set; which is a documented reason to ignore the LD_LIBRARY_PATH : Ok

None of these actions seem to solve my problem. Is there an obvious thing I forgot to consider?

gyin
  • 199
  • 6

1 Answers1

0

It's now fixed. That was a stupid mistake of me.

I initially had a LD_LIBRARY_PATH without the good directory so fixed it, but... After changing the LD_LIBRARY_PATH, I issued a apachectl restart which, as documented by Apache only kills the child processes, and spawns new children from the existing parent.

So new children kept having the old version of the LD_LIBRARY_PATH.

Now I'm not really sure to understand why I saw the "good" LD_LIBRARY_PATH with gdb's show environment. But this is a different story. I'll close my initial question, which is now solved.

gyin
  • 199
  • 6
  • 1
    When building MySQLdb Python module, set LD_RUN_PATH environment variable to directory where MySQL shared libraries are and it will embedd that knowledge in the Python C extension and don't have to worry about setting LD_LIBRARY_PATH at runtime. – Graham Dumpleton Jul 11 '12 at 01:04