PHP7 CLI attempts to load xdebug twice - "Cannot load Xdebug - it was already loaded"

Question

After upgrading Ubuntu from 14.04 to 16.04, PHP CLI started complaining about xdebug:

$ php -v
Cannot load Xdebug - it was already loaded
PHP 7.0.13-0ubuntu0.16.04.1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.13-0ubuntu0.16.04.1, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans

There is only one.ini file:

$ ls -la /etc/php/7.0/cli/conf.d/ | grep xdebug
lrwxrwxrwx 1 root root   38 Jan 19 11:41 20-xdebug.ini -> /etc/php/7.0/mods-available/xdebug.ini

And it's only referenced once in this output from php -i :

$ php -i | grep -i configuration
Cannot load Xdebug - it was already loaded
Configuration File (php.ini) Path => /etc/php/7.0/cli
Loaded Configuration File => /etc/php/7.0/cli/php.ini
Configuration

And there's only one reference to xdebug in the entire directory (so it's not being included twice):

/etc/php/7.0$ grep -r xdebug *
mods-available/xdebug.ini:zend_extension=xdebug.so
mods-available/xdebug.ini:[xdebug]
mods-available/xdebug.ini:xdebug.remote_enable=1
mods-available/xdebug.ini:xdebug.remote_autostart=1
mods-available/xdebug.ini:xdebug.remote_port=9000
mods-available/xdebug.ini:xdebug.idekey=PHPSTORM

If I do $ phpdismod xdebug I get the following output, suggesting that it still has xdebug loaded:

$ php -v
PHP 7.0.13-0ubuntu0.16.04.1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.13-0ubuntu0.16.04.1, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans

Having done that it is no longer present in the apache config as shown by phpinfo() .

How do I fix this?

---

Edit: Additional output as requested:

$ php --ini
Cannot load Xdebug - it was already loaded
Configuration File (php.ini) Path: /etc/php/7.0/cli
Loaded Configuration File:         /etc/php/7.0/cli/php.ini
Scan for additional .ini files in: /etc/php/7.0/cli/conf.d
Additional .ini files parsed:      /etc/php/7.0/cli/conf.d/10-mysqlnd.ini,
/etc/php/7.0/cli/conf.d/10-opcache.ini,
/etc/php/7.0/cli/conf.d/10-pdo.ini,
/etc/php/7.0/cli/conf.d/15-xml.ini,
/etc/php/7.0/cli/conf.d/20-bcmath.ini,
/etc/php/7.0/cli/conf.d/20-calendar.ini,
/etc/php/7.0/cli/conf.d/20-ctype.ini,
/etc/php/7.0/cli/conf.d/20-curl.ini,
/etc/php/7.0/cli/conf.d/20-dom.ini,
/etc/php/7.0/cli/conf.d/20-exif.ini,
/etc/php/7.0/cli/conf.d/20-fileinfo.ini,
/etc/php/7.0/cli/conf.d/20-ftp.ini,
/etc/php/7.0/cli/conf.d/20-gd.ini,
/etc/php/7.0/cli/conf.d/20-gettext.ini,
/etc/php/7.0/cli/conf.d/20-iconv.ini,
/etc/php/7.0/cli/conf.d/20-json.ini,
/etc/php/7.0/cli/conf.d/20-mbstring.ini,
/etc/php/7.0/cli/conf.d/20-mcrypt.ini,
/etc/php/7.0/cli/conf.d/20-mysqli.ini,
/etc/php/7.0/cli/conf.d/20-pdo_mysql.ini,
/etc/php/7.0/cli/conf.d/20-pdo_sqlite.ini,
/etc/php/7.0/cli/conf.d/20-phar.ini,
/etc/php/7.0/cli/conf.d/20-posix.ini,
/etc/php/7.0/cli/conf.d/20-readline.ini,
/etc/php/7.0/cli/conf.d/20-shmop.ini,
/etc/php/7.0/cli/conf.d/20-simplexml.ini,
/etc/php/7.0/cli/conf.d/20-sockets.ini,
/etc/php/7.0/cli/conf.d/20-sqlite3.ini,
/etc/php/7.0/cli/conf.d/20-sysvmsg.ini,
/etc/php/7.0/cli/conf.d/20-sysvsem.ini,
/etc/php/7.0/cli/conf.d/20-sysvshm.ini,
/etc/php/7.0/cli/conf.d/20-tokenizer.ini,
/etc/php/7.0/cli/conf.d/20-wddx.ini,
/etc/php/7.0/cli/conf.d/20-xdebug.ini,
/etc/php/7.0/cli/conf.d/20-xmlreader.ini,
/etc/php/7.0/cli/conf.d/20-xmlwriter.ini,
/etc/php/7.0/cli/conf.d/20-xsl.ini

---

$ cat /etc/php/7.0/mods-available/xdebug.ini 
zend_extension=xdebug.so
[xdebug]
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_port=9000
xdebug.idekey=PHPSTORM

---

As this is still an issue I have found some further detail:

Paths:

$ ls -la /usr/bin/php
lrwxrwxrwx 1 root root 21 Apr 18  2017 /usr/bin/php -> /etc/alternatives/php
$ ls -la /etc/alternatives/php
lrwxrwxrwx 1 root root 15 Feb 12 15:43 /etc/alternatives/php -> /usr/bin/php7.1

php:

$ php -v
Cannot load Xdebug - it was already loaded
PHP 7.1.15-1+ubuntu16.04.1+deb.sury.org+2 (cli) (built: Mar  6 2018 11:10:13) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.1.15-1+ubuntu16.04.1+deb.sury.org+2, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.6.0, Copyright (c) 2002-2018, by Derick Rethans

php7.1:

$ php7.1 -v
PHP 7.1.15-1+ubuntu16.04.1+deb.sury.org+2 (cli) (built: Mar  6 2018 11:10:13) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.1.15-1+ubuntu16.04.1+deb.sury.org+2, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.6.0, Copyright (c) 2002-2018, by Derick Rethans

The interesting thing there is that the php binary is identical to php7.1 but when called as the specific it doesn't show the already loaded message.

---

Edit, 20181006:

I still have this issue. The image below is a diff of the output of the two php --ini calls. As you can see, the sets of ini files loaded are the same.

They are also the same symlinked binaries:

ben@ben-work:~$ which php
/usr/bin/php
ben@ben-work:~$ ls -la /usr/bin/php
lrwxrwxrwx 1 root root 21 May 15 16:07 /usr/bin/php -> /etc/alternatives/php
ben@ben-work:~$ ls -la /etc/alternatives/php
lrwxrwxrwx 1 root root 15 May 30 10:13 /etc/alternatives/php -> /usr/bin/php7.1
ben@ben-work:~$ which php7.1 
/usr/bin/php7.1

Answer 1

I've fixed this by removing zend_extension=xdebug.so as I already enabled it in my docker container with docker-php-ext-enable xdebug . It might be that it's enabled for you as well.

Answer 2

In Arch Linux the package xdebug generates the following configuration:

/etc/php/conf.d/xdebug.ini
----------
zend_extension=xdebug.so
xdebug.remote_enable=on
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
#xdebug.max_nesting_level=300

This loads twice the same zend_extension=xdebug.so located in /etc/php/php.ini

Answer 3

You need serch the zend_extension declaration in your PHP config dir, for example

grep -Hnir zend_extension /etc/php/7.2/

The command will tell you where you the files:line where is defined the extension, in my case:

/etc/php/7.2/mods-available/xdebug.ini:2:zend_extension=/usr/lib/php/20170718/xdebug.so
/etc/php/7.2/cli/php.ini:1938:; zend_extension = /usr/lib/php/20170718/xdebug.so
/etc/php/7.2/apache2/php.ini:368:zend_extension = /usr/lib/php/20170718/xdebug.so

Here, both cli/php.ini and apache2/php.ini are the same config file but mods-available/xdebug.ini is another file with only xdebug info.

You can comment out or move the lines about xdebug in your php.ini to xdebug.ini and create a joined config under [xdebug] section.

Example:

#xdebug.ini
[xdebug]
zend_extension=/usr/lib/php/20170718/xdebug.so
xdebug.collect_params=4
xdebug.collect_vars=on
xdebug.remote_autostart=on

xdebug.var_display_max_children=128
xdebug.var_display_max_data=4086
xdebug.var_display_max_depth=10

Answer 4

Debian and derivate:

I fixed it locating my php.ini, changing the zend_extension=xdebug.so to the old (so I guess the same would happend commenting the line) zend_extension_ts=zdebug.so .

Then with: php -i | grep xdebug php -i | grep xdebug there should be only one conf.d with the zend_extension=xdebug.so . If there were more than one delete the rest of entries.

Answer 5

我遇到了同样的问题，并通过删除 php --version 显示的 php 文件夹中的 php.ini 文件中的额外代码行zend_extension="xdebug.so"解决了它，通常在/usr/local/etc/php/ for mac用户。

Answer 6

The cause may indeed be duplicate config files. In my case 15-xdebug.ini had been added by dnf install php-pecl-xdebug3-3.0.4-1.el8.remi.8.0.x86_64 . Listing the INI files shows this:

ls /etc/php*/*xdebug.ini

/etc/php-cli.d/99-xdebug.ini  /etc/php.d/15-xdebug.ini  /etc/php.d/99-xdebug.ini  /etc/php-zts.d/15-xdebug.ini

Answer 7

For users who face the same problem.

In my scenario, it was problem with php cli so every time I tried to get to php in the console, I was getting notice: Cannot load the ionCube PHP Loader - extension already loaded

I guess it will be similar to other extensions.

What I have finally done is:

cd /opt/cpanel/ea-php56/root/etc
grep -r "cube" .
# now I saw two files loading the .so files:
# ./php.d/01-ioncube.ini:zend_extension="/opt/cpanel/ea-php56/root/usr/lib64/php/modules/ioncube_loader_lin_5.6.so"
# ./php.d/pecl.ini:zend_extension="/opt/cpanel/ea-php56/root/usr/lib64/php/modules/ioncube_loader_lin_5.6.so"
mv php.d/pecl.ini .

That was it.

Answer 8

this is just what i faced tried to solve this, this might help someone to figure it out.

obviously, its declared in two places, but no harm in that. the case for me is that it is declared in the /etc/php/8.1/cli/conf.d/99-xdebug.ini ( this is the default for some reason )

and here /etc/php/8.1/cli/php.ini

by executing php -i | grep php.ini php -i | grep php.ini

you ll find that it mentions the second location only ( my assumption thatit ovverides the firt loading location )

❯ php -i | grep php.ini
Configuration File (php.ini) Path => /etc/php/8.1/cli
Loaded Configuration File => /etc/php/8.1/cli/php.ini

so i commented out the zend_extension line from the second ini file.

Answer 9

After https://stackoverflow.com/users/2192660/javier-domenech suggestion, that was exact my case. I've discovered two files:

/etc/php/7.4/cli/conf.d/20-xdebug.ini, /etc/php/7.4/cli/conf.d/99-xdebug.ini.

After deleting the 99-etc, then laravel php server stopped complaining about not finding xdebug (alhough it xdebug worked fine whatsoever).

But most important: This has caused a real exception when trying to run phpunit test suite: PHPUnit\Framework\Exception: Xdebug: [Step Debug] Could not connect to debugging client This virtually prevented phpunit from running.

The prior action of deletion, in combination with setting the attribute: processIsolation="true" inside of phpunit.xml also solved this weird phpunit issue.