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

What is the output of `php --ini` (it's better than `php -i | grep -i configuration`)? PHP must be parsing other ini files somewhere... — LazyOne, Jan 19 '17 at 12:41
Please check all .ini for `zend_extension=` lines. You may try `extension=` to see all extensions ... but xdebug can be loaded first way only. BUT so far it must be `/etc/php/7.0/cli/conf.d/20-xdebug.ini` while you seems to have looked at `mods-available/xdebug.ini` only — LazyOne, Jan 19 '17 at 12:48
OK .. so it's the same file. And what is the *current* content of that file? — LazyOne, Jan 19 '17 at 12:51
There's only the one zend_extension line for xdebug, in `/etc/php/7.0/mods-available/xdebug.ini` — bcmcfc, Jan 19 '17 at 12:51
Contents match the grep above, will add the contents to the end of the question. — bcmcfc, Jan 19 '17 at 12:52
So .. if you comment that out it will not load xdebug now? Unfortunately I cannot tell what `$ phpdismod xdebug` disables and where (not a Linux/Mac user myself). — LazyOne, Jan 19 '17 at 12:55
phpenmod/phpdismod are modeled after apache's a2enmod/a2dismod - it creates and deletes symlinks between conf.d inside both the cli and apache2 directories and the mods-available directory, so that your config is the same for both. Running it is effectively the same as commenting out the extension line. — bcmcfc, Jan 19 '17 at 12:57
@bcmcfc did you figure this one out? If so, could you provide an answer, please? I'm having the same problem. — panepeter, Apr 11 '17 at 15:57
Seems that you had 2 xdebug.ini files to be loaded. _/etc/php/7.0/cli/conf.d/20-xdebug.ini_ and _/etc/php/7.0/mods-available/xdebug.ini_ Try to comment one of them. — Marcos Regis, Aug 22 '17 at 19:04
@MarcosRegis it's not the case or mods-available would be listed in the output of php --ini, there is only one xdebug file referenced — bcmcfc, Oct 06 '18 at 10:00

score 54 · Answer 1 · answered Jun 14 '17 at 16:16

54

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.

answered Jun 14 '17 at 16:16

Magarusu

982
10
14

I'm not using Docker. – bcmcfc Jun 15 '17 at 07:39
3

Doesn't matter, try removing 'zend_extension=xdebug.so' from /etc/php/7.0/mods-available/xdebug.ini. – Magarusu Jun 16 '17 at 08:15
When I remove that then xdebug doesn't get loaded at all. – bcmcfc Jun 16 '17 at 09:35
Oh damn, sorry I couldn't help more. This was the problem for me as it already got loaded from somewhere else. It might be that the file is actually loaded twice for you and maybe not from the directory you searched in. I'll leave my answer as well as it might help others. Hope you manage to find the issue. – Magarusu Jun 16 '17 at 12:38
No worries, it may help someone else. – bcmcfc Jun 16 '17 at 12:41
well you shuld make this accepted answer. this saved me some time. thanks – mohammad fallah.rasoulnejad Dec 17 '19 at 13:35
When I removed the xdebug.xo from the xdebug.ini, the problem got fixed. thanks – senthil Feb 26 '21 at 06:40
in my case zedn_extension line was duplicated after os upgrade – Maciek Rek Aug 09 '22 at 06:24

score 16 · Answer 2 · answered Jan 08 '19 at 14:26

16

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

answered Jan 08 '19 at 14:26

dnloop

161
2
5

1

This solved my problem (Fedora Core 29, newly upgraded from FC26) To see ini files loaded : `php --ini` => chances are there is `xdebug.ini` in the list – Arcesilas Jan 16 '19 at 17:01
For me on mac using homebrew a recent upgrade edited my default php.ini settings and tacked on these new xdebug settings on top of my line including it in a previous version. – gillytech Jul 22 '19 at 03:30
Solved the problem in Ubuntu 20, commenting out the line `zend_extension = xdebug.so` – Fellipe Sanches Jul 07 '20 at 20:09

score 10 · Answer 3 · answered Mar 06 '20 at 20:53

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

score 5 · Answer 4 · edited Nov 24 '22 at 11:48

5

I had the same issue and solved it by removing extra line of code zend_extension="xdebug.so" inside the php.ini file.

The php.ini could be in /usr/local/etc/php/ for mac users but you can run the following command to locate the php.ini file:

$ php -i | grep php.ini

edited Nov 24 '22 at 11:48

A1rPun

16,287
7
57
90

answered Aug 24 '18 at 15:16

farnoosh

301
4
6

Thanks! This worked for me (macOS High Sierra). Installed PHP using Homebrew (`brew install php@7.3`) and xdebug using pecl (`pecl install xdebug`). PHP then showed me this message. At the top of `php.ini`, the `zend_extension="xdebug.so"` was added twice. – Robin van Baalen Dec 18 '19 at 16:28

score 4 · Answer 5 · answered Mar 12 '18 at 10:37

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 there should be only one conf.d with the zend_extension=xdebug.so. If there were more than one delete the rest of entries.

Martin Zeitler · Answer 6 · 2021-10-06T12:46:14.907

3

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

edited Oct 06 '21 at 12:46

answered Oct 06 '21 at 12:36

Martin Zeitler

1
19
155
216

score 1 · Answer 7 · answered Aug 20 '18 at 06:28

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.

score 1 · Answer 8 · answered May 02 '22 at 12:15

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

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 .

Grigoreas P. · Answer 9 · 2022-12-05T12:20:41.937

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.

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

9 Answers9