Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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]   File "/remote/projects1/pdrtke/python/lib/python2.6/site-packages/Django-1.3-py2.6.egg/django/utils/", line 35, in import_module
[Tue Jul 10 12:52:02 2012] [error] [client]     __import__(name)
[Tue Jul 10 12:52:02 2012] [error] [client]   File "/remote/projects1/pdrtke/python/lib/python2.6/site-packages/Django-1.3-py2.6.egg/django/db/backends/mysql/", line 14, in <module>
[Tue Jul 10 12:52:02 2012] [error] [client]     raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
[Tue Jul 10 12:52:02 2012] [error] [client] ImproperlyConfigured: Error loading MySQLdb module: 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 ... actions requiring database support work: Ok
  • Check that LD_LIBRARY_PATH points to a directory where is available : Ok
  • Attach the httpd process with gdb, and do a show env : The LD_LIBRARY_PATH points to 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 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
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
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

Your Answer


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.