PHP7 CLI tente de charger xdebug deux fois - "Impossible de charger Xdebug - il était déjà chargé"

Question

Après avoir mis à jour Ubuntu de 14.04 à 16.04, PHP CLI a commencé à se plaindre de 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

Il n'y a qu'un seul fichier .ini:

$ 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

Et il n'est référencé qu'une seule fois dans cette sortie à partir de 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

Et il n'y a qu'une seule référence à xdebug dans tout le répertoire (pour ne pas l'inclure deux fois):

/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

Si je fais $ phpdismod xdebug j'obtiens la sortie suivante, suggérant que xdebug est toujours chargé:

$ 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

Ceci fait, il n’est plus présent dans la configuration d’Apache comme indiqué par phpinfo().

Comment puis-je réparer ça?

Edit: Sortie supplémentaire demandée:

$ 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

Comme cela reste un problème, j'ai trouvé quelques détails supplémentaires:

Chemins:

$ 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

La chose intéressante ici est que le binaire php est identique à php7.1, mais lorsqu'il est appelé en tant que spécifique, il ne montre pas le message déjà chargé.

Edit, 20181006:

J'ai toujours ce problème. L'image ci-dessous est un diff de la sortie des deux appels php --ini. Comme vous pouvez le constater, les ensembles de fichiers ini chargés sont les mêmes.

Ce sont aussi les mêmes binaires symlink:

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

Magarusu · Answer

J'ai résolu ce problème en supprimant zend_extension=xdebug.so car je l'avais déjà activé dans mon conteneur de menu fixe avec docker-php-ext-enable xdebug. Il se peut que cela soit également possible pour vous.

vivoconunxino · Answer

Debian et ses dérivés:

Je l'ai corrigé en localisant mon php.ini, en changeant le zend_extension=xdebug.so à l'ancien (donc je suppose qu'il en serait de même en commentant la ligne) zend_extension_ts=zdebug.so.

Ensuite, avec: php -i | grep xdebug, il devrait y avoir un seul conf.d avec le zend_extension=xdebug.so. S'il y en avait plusieurs, supprimez le reste des entrées.

dnloop · Answer

Dans Arch Linux, le paquet xdebug génère la configuration suivante:

/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

Ceci charge deux fois le même zend_extension=xdebug.so situé dans /etc/php/php.ini

JonnieJS · Answer

Pour les utilisateurs qui font face au même problème.

Dans mon scénario, il y avait un problème avecphp clialors chaque fois que j'essayais de me rendre à php dans la console, je recevais un message:Cannot load the ionCube PHP Loader - extension already loaded

Je suppose que ce sera similaire à d'autres extensions.

Ce que j'ai finalement fait est:

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 .

C'était ça.

farnoosh · Answer

J'ai eu le même problème et je l'ai résolu en supprimant une ligne supplémentaire de code zend_extension="xdebug.so" dans le fichier php.ini du dossier php que php --version montrait, généralement à l'intérieur de /usr/local/etc/php/ pour les utilisateurs de mac.