Deshabilitar xdebug al ejecutar composer


98

Cuando lo ejecuto composer diagnose, aparece el siguiente error:

La extensión xdebug está cargada, esto puede ralentizar un poco a Composer. Se recomienda deshabilitarlo al usar Composer.

¿Cómo puedo desactivar xdebug solo cuando estoy ejecutando Composer?

Respuestas:


81

Actualización : el problema se ha solucionado en Composer 1.3 . Actualice el compositor a la última versión ejecutando composer self-update, en lugar de intentar la siguiente solución.


Aquí está mi modificación del código de @ezzatron. He actualizado el script para detectar archivos ini de la salida de phpinfo.

#!/bin/sh

php_no_xdebug () {
    temporaryPath="$(mktemp -t php.XXXX).ini"

    # Using awk to ensure that files ending without newlines do not lead to configuration error
    php -i | grep "\.ini" | grep -o -e '\(/[a-z0-9._-]\+\)\+\.ini' | grep -v xdebug | xargs awk 'FNR==1{print ""}1' | grep -v xdebug > "$temporaryPath"

    php -n -c "$temporaryPath" "$@"
    rm -f "$temporaryPath"
}

php_no_xdebug /usr/local/bin/composer.phar $@
# On MacOS with composer installed using brew, comment previous line
# Install jq by executing `brew install jq` and uncomment following line.
# php_no_xdebug /usr/local/Cellar/composer/`brew info --json=v1 composer | jq -r '.[0].installed[0].version'`/libexec/composer.phar $@

3
Esta es, con mucho, la solución más elegante al problema, en mi humilde opinión. ¡Gracias Joyce!
Thomas Hansen

2
Mejor. Guión. Ever
Maciej Paprocki

1
Tuve que ajustar el shebang a en bin/bashlugar de /bin/sh, ya que a este último no le gustó la functionpalabra clave (Ubuntu 14.04 LTS).
ashnazg

Actualicé el código y eliminé la palabra clave de función para una mejor compatibilidad.
Joyce Babu

1
Puede confirmar que está ejecutando la última versión ejecutandocomposer self-update
Joyce Babu

77

Este comando deshabilitará el módulo PHP5 Xdebug para CLI (y por lo tanto el compositor):

sudo php5dismod -s cli xdebug

Elimina el enlace simbólico xdebug.ini de/etc/php5/cli/conf.d/

Esto se sugirió en http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli/

Tenga en cuenta que para Ubuntu 16.04 probablemente necesite ejecutarlo así:

sudo phpdismod -s cli xdebug

4
Agregué los dos alias alias xdebug-on='sudo php5enmod -s cli xdebug'y alias xdebug-off='sudo php5dismod -s cli xdebug', por lo tanto, ahora es fácil habilitar xdebug-ony deshabilitar xdebug-offxdebug.
Daniel Mecke

No portátil. Probablemente solo para Linux.
Diti

Funciona muy bien en la caja Laravel Homestead (Ubuntu / Debian). Una descripción más larga de cómo funciona: laracasts.com/discuss/channels/forge/disable-xdebug
Justin

2
gracias por esto :) pero tengo ubuntu 16.04 y si alguien necesita usar esto, simplemente ejecute sudo phpdismod -s cli xdebug
Angel M.

¿Qué hay de php7 en ubuntu? ¿Solo necesito eliminar el enlace simbólico? /etc/php/7.0/cli/conf.d
gastonnina

40

No creo que haya una opción para configurar PHP para que pueda cargar diferentes configuraciones de acuerdo con el script de destino. Al menos, no sin duplicar archivos .ini ...

Sin embargo, puede agregar estas opciones al ejecutar composer con php:

php -n -d extension=needed_ext.so composer.phar

-nle dirá a PHP que ignore cualquier php.ini. Esto evitará que xdebug se cargue para este mismo comando.

-doptions le permite agregar cualquier opción que desee (por ejemplo, active required_ext.so). Puede utilizar varias -dopciones. Por supuesto, esto es opcional, es posible que no lo necesite.

Luego puede crear un alias, para volverlo azucarado nuevamente.

Una solución típica (porque el compositor necesita json):

php -n -d extension=json.so composer.phar

greg0ire> mi solución, basada en eso:

#!/bin/bash
options=$(ls -1 /usr/lib64/php/modules| \

    grep --invert-match xdebug| \

    # remove problematic extensions
    egrep --invert-match 'mysql|wddx|pgsql'| \

    sed --expression 's/\(.*\)/ --define extension=\1/'| \

    # join everything together back in one big line
    tr --delete '\n'
)

# build the final command line
php --no-php-ini $options ~/bin/composer $*

alias composer=/path/to/bash/script.sh

Se ve feo (intenté y no pude hacer eso con xargs), pero funciona ... Sin embargo, tuve que deshabilitar algunas extensiones, de lo contrario, recibo las siguientes advertencias:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_pgsql.so' - /usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/wddx.so' - /usr/lib64/php/modules/wddx.so: undefined symbol: php_XML_SetUserData in Unknown on line 0

Lo intenté -nayer y tuve un problema porque me faltaba la pharextensión. Intentaré agregar más y más extensión hasta que funcione, creo que esta es una buena solución. Según el alias, ya tengo algunos alias de zsh que no mantengo. Tal vez intente reemplazar el binario con un script bash, o ver si puedo configurar los alias.
greg0ire

Sin embargo, el problema con este enfoque de lista blanca es que la lista blanca puede crecer dependiendo de lo que la gente requiera en su composer.json, por ejemplo, "ext-ldap": "*", o simplemente dependiendo de lo que se necesita para que las tareas posteriores a la instalación se ejecuten correctamente. … Si tan solo hubiera una manera de
incluir

1
Intentaré hacer algo con la salida dephp -m
greg0ire

Me viene a la mente, pero supongo que usa xdebug en un entorno de desarrollo. ¿Es el compositor tan lento que necesita este ajuste?
Gui-Don

Oh no, acabo de ver esto en la salida de diagnose, y como estoy construyendo contenedores de Docker de desarrollo para mi equipo, la mejora de velocidad más pequeña podría beneficiar a todos ellos
greg0ire

14

Al crear un alias, suprimirá ese composer xdebugmensaje de error.

Simplemente agregue esta línea a ~/.bash_aliasessu sistema y debería funcionar sin problemas.

alias composer="php -n /usr/local/bin/composer"

Vuelva a cargar el shell para que el nuevo alias composeresté disponible.

source ~/.bash_profile

USO:

$ composer --version

NOTA:
No es necesario que utilice ningún otro parámetro.
Dependiendo de su sistema, es posible que tenga un .bashrcarchivo .bash_profile.

ACTUALIZAR:

Como @AlexanderKachkaev menciona en los comentarios, no vale la pena agregar memory_limit de la siguiente manera para evitar fallar en algunas situaciones:

alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"

3
Esto no funcionará muy bien tan pronto como se necesite una de las extensiones en los scripts posteriores a la instalación o actualización ... Sin embargo, podría ser una buena solución en proyectos simples.
Greg0ire

1
La -nopción deshabilita la Pharextensión, por lo que es posible que no se ejecute desdecomposer.phar
brzuchal

1
Esto funcionó para mí. Además, desactivé el límite de memoria para evitar alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"
fallas

Esta solución es bastante simple y viable para mi situación. La sugerencia de límite de memoria de @AlexanderKachkaev es imprescindible. Sea bueno para editar la respuesta.
Henry

12

Se me ocurrió una respuesta que funciona bastante bien para OSX, y probablemente podría adaptarse para cualquier versión de PHP que cargue sus extensiones usando archivos .ini individuales en el "directorio ini adicional":

#!/bin/sh

function php-no-xdebug {
    local temporaryPath="$(mktemp -t php-no-debug)"

    find /opt/local/etc/$1/php.ini /opt/local/var/db/$1/*.ini ! -name xdebug.ini | xargs cat > "$temporaryPath"
    php -n -c "$temporaryPath" "${@:2}"
    rm -f "$temporaryPath"
}

alias composer="php-no-xdebug php56 ~/bin/composer"

¡Excelente! Creé un script de propósito general basado en esto para Ubuntu 14.04-15.10 gist.github.com/perk11/816c4e64023ea26976cf
Konstantin Pereiaslov

Fantástico, funciona bien en Mac OS, en brew instalado php 7.1. TY!
Antonio Carlos Ribeiro

7

Normalmente creo un script de shell por proyecto, ya que cada proyecto tiene otra versión de PHP. Está en un /bin/directorio al lado composer.phary composer.jsonY corro como ./bin/composeren mi directorio del proyecto.

Se ve así (para php56)

#!/bin/sh
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

COMPOSER_DISABLE_XDEBUG_WARN=1 /opt/local/bin/php56 \
    -d xdebug.remote_enable=0 -d xdebug.profiler_enable=0 \
    -d xdebug.default_enable=0 $DIR/../composer.phar "$@"

Las -dopciones desactivan efectivamente xdebug. La COMPOSER_DISABLE_XDEBUG_WARN=1parte deshabilita los problemas del compositor de advertencia.

Se prefiere deshabilitar la extensión xdebug (ver solución de problemas del compositor ), pero personalmente me gusta el script más simple.

Algunos tiempos en mi máquina: 2 Ejecutar con xdebug e ini habilitado: 1m33

Ejecutar con xdebug pero ini-disabled: 0m19

Ejecutar sin xdebug: 0m10


Creo que ya que está deshabilitando XDebug, no necesita COMPOSER_DISABLE_XDEBUG_WARN=1: si recibe una advertencia, solo significa que su scrit no funciona. Definir xdebug.remote_autostartparece inútil si la depuración remota está desactivada.
greg0ire

Tienes razón sobre xdebug.remote_autostart. Acerca de la eficacia de los scripts: Composer comprueba si la extensión xdebug está cargada, no si realmente está haciendo algo, mira el código aquí . Las opciones ini funcionan bien en scripts php "normales", pero de nuevo: no he hecho pruebas de rendimiento ...
Joost

(Finalmente) encontré la parte relevante en el manual del compositor sobre esta solución de problemas: impacto de xdebug en el compositor . Explica que deshabilitar todas las opciones de xdebug a través de las banderas ini no es suficiente para mitigar los problemas de rendimiento. Entonces mi guión no funcionará. ¡Demasiado!
Joost

Hice algo de sincronización (en Mac OS X) y debo decir que estoy bastante contento con las mejoras de rendimiento con mi script. Con las opciones de xdebug habilitadas , tarda 1m33 , con las opciones desactivadas , 0m19 . Sin la extensión xdebug, se necesitan 0m10 .
Joost

Ok, de todos modos hay una mejora. No es la mejor mejora disponible, pero es una gran mejora de todos modos (al menos en OS X)
greg0ire

6

Si usa PHPStorm, la última versión (2016.2) viene con una función para habilitar XDebug para scripts CLI bajo demanda, lo que significa que simplemente puede desactivar XDebug globalmente en su máquina de desarrollo. El IDE lo habilitará sobre la marcha cuando el código dentro de sus proyectos lo necesite.

https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/

PhpStorm 2016.2 presenta el modo Xdebug On Demand donde puede deshabilitar Xdebug para su instalación global de PHP, y PhpStorm solo lo habilitará cuando sea necesario: cuando esté depurando sus scripts o cuando necesite informes de cobertura de código.

Necesita editar sus preferencias de Intérpretes PHP para incluir la ruta a XDebug, como se describe en el artículo vinculado.

Para mí, esta parece la solución perfecta, ya que normalmente solo quiero XDebug mientras estoy en el IDE.

Sin embargo, XDebug tiene otros usos potenciales cuando está "fuera de línea", por ejemplo, volcados de pila extendidos en registros de error, que perdería si lo apagara globalmente. Por supuesto, no debería tener XDebug habilitado en producción, por lo que esto se limitaría a casos de uso como pruebas beta o scripts CLI de prueba automatizada en desarrollo.


5

En lugar de confundirse con la habilitación o deshabilitación temporal del módulo PHP, cuando es posible que tenga procesos concurrentes usando PHP (por ejemplo, como parte de una canalización de CI), puede decirle a PHP que apunte a un directorio de carga de módulo diferente.

Si bien esto es similar a algunas de las soluciones mencionadas anteriormente, esto resuelve algunos casos extremos, lo cual es muy útil cuando lo usa Jenkins u otro corredor de CI que ejecuta pruebas en la misma máquina al mismo tiempo.

La forma más sencilla de hacer esto es usar la variable de entorno PHP_INI_SCAN_DIR

Usar esto en un script o en una tarea de compilación es fácil:

export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug php composer install

Por supuesto, primero querrá preparar /etc/php.d.noxdebug, haciendo algo como:

mkdir /etc/php.d.noxdebug cp /etc/php.d/* /etc/php.d.noxdebug rm /etc/php.d.noxdebug/xdebug.ini

Esto significa que tiene un entorno similar al antiguo entorno php, con solo un módulo faltante. Lo que significa que no necesita preocuparse por la necesidad de cargar los módulos phar / json como lo haría con la solución php -n.


Usaría enlaces simbólicos en lugar de simplemente copiar archivos ini.
greg0ire

1
Evité usar enlaces simbólicos porque da la impresión de que las carpetas están sincronizadas, mientras que los nuevos módulos no se incluirían automáticamente en la carpeta 'noxdebug'.
KHobbits

4

Se me ocurrió una solución para el instalador de Composer basado en Windows: debería funcionar para cualquier instalación de Composer, básicamente hace una copia del archivo INI cargado y comenta la extensión xdebug zend, luego carga ese archivo de configuración cuando ejecuta Composer .

Abrí un problema para ver si les gustaría integrar este cambio:

https://github.com/composer/windows-setup/issues/58

Puede encontrar mis instrucciones y código allí.


Simple y efectivo :) ¿Tiene que aplicar esto nuevamente después de actualizar el compositor a través de la actualización automática?
marcovtwout

4

Como se señaló en la respuesta de Joyce , este problema ya no existe en la última versión de Composer.

La documentación de Composer se ha actualizado para tener en cuenta esto . Detalla cómo puede habilitar xdebug con Composer (si es necesario).

Puede actualizar su versión de Composer utilizando la actualización automática .

En mi Mac tuve que hacer: sudo php /opt/local/bin/composer self-update

En este número se pueden encontrar más detalles sobre esto en el contexto de una instalación PHP de Homebrew .


¡Eso es genial! ¿Sabes dónde están las relaciones públicas para este cambio? Lo necesito en otra aplicación CLI
Tomáš Votruba

3

Manipulación directa de la configuración de PHP

Aquí está mi contribución basada en una instalación de PHP instalada por Homebrew en Mac OS X.

Es un contenedor de script de shell, diseñado para guardarse como un archivo ejecutable en /usr/local/bin/composer, con el binario de Composer en /usr/local/bin/composer.phar:

#!/bin/sh
sed -i '' -e 's:zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
/usr/local/bin/php /usr/local/bin/composer.phar "$@"
sed -i '' -e 's:;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini

teoría de operación

El script de envoltura:

  • usa sed para modificar temporalmente el archivo de configuración, deshabilitando Xdebug (línea 2)
  • ejecuta Composer, pasando por args al comando (línea 3)
  • usa sed para restaurar el archivo de configuración, volviendo a habilitar Xdebug (línea 4)

El script está acoplado a una instalación OS X / Homebrew de PHP 5.5. Las rutas deben ajustarse para que funcionen con otras versiones de PHP y los diseños de directorio de otros sistemas operativos y administradores de paquetes. Tenga en cuenta también que algunas versiones de sed no necesitan el argumento de cadena vacía que sigue a la -iopción.

Utilizador de advertencias

El script es sencillo, ya que funciona directamente en los archivos principales de configuración de PHP, sin embargo , esto también es un inconveniente: Xdebug también se desactivará para cualquier script que se ejecute simultáneamente con este script.

En mi entorno de desarrollo, esta es una compensación aceptable, dado que Composer se ejecuta manualmente y solo ocasionalmente; sin embargo, es posible que no desee utilizar esta técnica si ejecuta Composer como parte de un proceso de implementación automatizado.


No estoy seguro de que suponga una diferencia en la forma en que Composer gestiona los errores. ¿Tiene algún ejemplo o inquietud específica? El script pretende ser una solución rápida al problema y no se ha probado exhaustivamente. Dicho esto, en el tiempo que lo he estado usando, ha funcionado sin problemas.
j13k

1
Mi preocupación es que es posible que no se ejecute la última línea del script.
greg0ire

2

En la mayoría de los casos, no necesita xdebug en el modo CLI. Si esto es aceptable para usted, puede configurar cli y cgi de manera diferente.

Entonces, si hace php-cli.ini y conf-cli.d cerca de salir del archivo php.ini, puede configurar cli y cgi de manera diferente (para cgi serían php.ini y conf.d ). Simplemente no ponga xdebug.ini en conf-cli.d.


2

Si instala Composer usando brew en OS X, puede usar este alias:

alias composer="php -n $(cat $(which composer) | grep composer.phar | awk '{print $7}')"

1

Mi solución rápida para una instalación de macports, con múltiples versiones de PHP, fue escribir este sencillo contenedor de shell para Composer:

/user/local/bin/composer-nodebug.sh

#!/bin/bash

sudo mv /opt/local/var/db/php53/xdebug.ini /opt/local/var/db/php53/xdebug.NOT
sudo mv /opt/local/var/db/php54/xdebug.ini /opt/local/var/db/php54/xdebug.NOT
sudo mv /opt/local/var/db/php55/xdebug.ini /opt/local/var/db/php55/xdebug.NOT
composer $1 $2 $3 $4 $5 $6 $7
sudo mv /opt/local/var/db/php53/xdebug.NOT /opt/local/var/db/php53/xdebug.ini
sudo mv /opt/local/var/db/php54/xdebug.NOT /opt/local/var/db/php54/xdebug.ini
sudo mv /opt/local/var/db/php55/xdebug.NOT /opt/local/var/db/php55/xdebug.ini

Luego ejecute cualquier comando del compositor como este:

sudo composer-nodebug.sh update

Inconvenientes:

  • requiere sudo (a menos que modifique los archivos INI)
  • si lo matas a mitad de camino, los archivos INI se modifican
  • requerirá que se agreguen futuras versiones de PHP.
  • mientras se ejecuta, otros procesos PHP se ven afectados

No elegante, pero simple.


Creo que hay un atajo que puedes usar en lugar de $1…$7… tal vez sea $@o algo así, tendrás que buscar.
greg0ire

> si lo matas a mitad de camino, los archivos INI se modifican, arregla eso al atrapar la señal de interrupción> requerirá que se agreguen futuras versiones de PHP. también puede solucionarlo con un bucle simple
greg0ire

1

Creación de un alias para que el compositor deshabilite xdebug y evite errores de memoria:

Agregue esta línea a su ~ / .bash_profile

alias composer='php -d xdebug.profiler_enable=0 -d memory_limit=-1 /usr/local/bin/composer'

Reinicie la terminal para que el nuevo alias esté disponible.


-3

Aquí está mi solución rápida para deshacerme de la advertencia Xdebug en la versión PHP5-cli. He eliminado el soporte de Xdebug para PHP5-cli en Ubuntu 14.04.

cd /etc/php5/cli/conf.d/

sudo rm 20-xdebug.ini

Ahora no más advertencias de Xdebug en PHP5-cli.


2
sudo phpdismod xdebugsería el método preferido para brutalizarrm
Jeff Puckett
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.