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 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?

share|improve this question
add comment

1 Answer

up vote 0 down vote accepted

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.

share|improve this answer
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 1:04
add comment

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.