What is causing the message "Failed loading /usr/lib/php/modules/xdebug.so" ("No such file or directory")?
When I run php --version (on CentOS release 6.4), I get:
# php --version
Failed loading /usr/lib/php/modules/xdebug.so: /usr/lib/php/modules/xdebug.so: cannot open shared object file: No such file or directory
PHP 5.4.19 (cli) (built: Aug 22 2013 08:03:53)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans
What is the source of the "Failed loading /usr/lib/php/modules/xdebug.so: /usr/lib/php/modules/xdebug.so: cannot open shared object file: No such file or directory" message?
I confirmed the location of my php.ini file using:
# php -a
Failed loading /usr/lib/php/modules/xdebug.so: /usr/lib/php/modules/xdebug.so: cannot open shared object file: No such file or directory
Interactive shell
php > echo php_ini_loaded_file() . "\n";
/etc/php.ini
And then I searched /etc/php.ini for "/usr/lib":
# fgrep "/usr/lib" /etc/php.ini
zend_extension=/usr/lib64/php/modules/xdebug.so
extension_dir = "/usr/lib64/php/modules"
PHP doesn't seem to be configured (in the php.ini) to look for xdebug.so in /usr/lib/php/modules/. So why am I getting that error message?
Update: In response to Sverri M. Olsen's comment suggesting the path to xdebug.so might need fixing, I did:
# fgrep "xdebug" /etc/php.ini
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=vmhostmachine
xdebug.remote_port=9000
xdebug.profiler_enable=1
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=/usr/xdebug
xdebug.profiler_append=1
xdebug.auto_trace=1
xdebug.trace_format=1
xdebug.collect_params=4
xdebug.collect_return=1
xdebug.trace_output_dir=/usr/xdebug
xdebug.trace_output_name=trace.%H.%t
xdebug.profiler_output_name=profile.%H.%t
And I confirmed the above path to xdebug.so is correct:
# ls -lh /usr/lib64/php/modules/xdebug.so
-rwxr-xr-x 1 root root 200K May 21 2013 /usr/lib64/php/modules/xdebug.so
Note also that Xdebug works.
Answer
In GNU/Linux systems derived from modern Red Hat releases (such as RHEL, Fedora, and CentOS), the PHP distribution may be divided into the primary .ini file residing at /etc/php.ini as well as a collection of other .ini files specific to extensions or packages installed as RPMs residing in /etc/php.d. At initialization, PHP will read /etc/php.d/*.ini after loading the main php.ini file.
It would seem that you have a stale file containing Xdebug settings residing in /etc/php.d. Grep for Xdebug in /etc/php.d to find the offender and remove it or comment out the relevant lines.
grep xdebug /etc/php.d/*.ini
If Xdebug was installed separately by a manual process and you manually modified the main /etc/php.ini to load the extension and configure its settings, that would explain why Xdebug otherwise works while you still see errors about its nonexistence at /usr/lib/php/modules/xdebug.so. This also could have happened if configuration files from /etc were copied from an old 32bit system to a 64bit system wherein modules reside at /usr/lib64/php/modules