Deshabilitar xdebug al ejecutar composer

7 minutos de lectura

avatar de usuario
greg0ire

al correr composer diagnoseObtuve el siguiente error :

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

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

avatar de usuario
joyce babu

Actualización: para Xdebug 3+:

A partir de Xdebug 3, es posible deshabilitar completamente Xdebug configurando la opción xdebug.mode a offo configurando la variable de entorno XDEBUG_MODE=off.

Es muy fácil deshabilitar Xdebug solo para composer, al crear un alias composer.

alias composer="XDEBUG_MODE=off \composer"

O

alias composer="php -dxdebug.mode=off $(where composer | fgrep -v composer: |  head -1)"

Puede agregar el alias a su $HOME/.bashrc para hacerlo permanente.


Actualización: Para Xdebug 1.3 – 3.0.0 :

El problema se ha solucionado en Compositor 1.3. Actualice el compositor a la última versión ejecutando composer self-updateen lugar de intentar la siguiente solución.


Para Xdebug <1.3

Aquí está mi modificación del código de @ezzatron. Actualicé 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" "[email protected]"
    rm -f "$temporaryPath"
}
    
php_no_xdebug /usr/local/bin/composer.phar [email protected]
# 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 [email protected]

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

    – Thomas Hansen

    13 de junio de 2016 a las 8:08

  • Mejor. Guion. Alguna vez

    – Maciej Paprocki

    25 de julio de 2016 a las 10:39


  • Tuve que ajustar el shebang a bin/bash más bien que /bin/shya que a este último no le gustaba el function palabra clave (Ubuntu 14.04 LTS).

    – Ashnazg

    18 de diciembre de 2016 a las 15:27

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

    –Joyce Babu

    19 de diciembre de 2016 a las 6:44

  • Puede confirmar que está ejecutando la última versión ejecutando composer self-update

    –Joyce Babu

    7 de marzo de 2018 a las 7:36

avatar de usuario
gobernante

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

sudo php5dismod -s cli xdebug

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

Esto fue sugerido 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

  • He añadido los dos alias. alias xdebug-on='sudo php5enmod -s cli xdebug' y alias xdebug-off='sudo php5dismod -s cli xdebug'por lo que ahora es fácil de habilitar xdebug-on y desactivar xdebug-off xdebug.

    – Daniel Mecke

    28 de febrero de 2016 a las 9:23

  • No portátil. Probablemente solo para Linux.

    – Diti

    28 de febrero de 2016 a las 12:52

  • 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

    12 de abril de 2016 a las 15:29


  • gracias por esto 🙂 pero tengo ubuntu 16.04 y si alguien necesita usar esto simplemente ejecute sudo phpdismod -s cli xdebug

    – Ángel M.

    20 mayo 2016 a las 17:54

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

    – gastonnina

    10 de septiembre de 2016 a las 3:32


avatar de usuario
Guión

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 esas opciones cuando ejecuta Composer con php:

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

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

-d opciones le permite agregar cualquier opción que desee (por ejemplo, active need_ext.so). Puedes usar múltiples -d opciones Por supuesto, esto es opcional, es posible que no lo necesite.

Luego puedes crear un alias, para que vuelva a ser azucarado.

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 hacerlo 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é -n ayer y tuve un problema porque me faltaba el phar extensión. Intentaré agregar más y más extensiones hasta que funcione, creo que esta es una buena solución. En cuanto al alias, ya tengo algunos alias zsh que no mantengo. Tal vez intente reemplazar el binario con un script bash, o vea si puedo configurar los alias.

    – greg0ire

    27 de junio de 2015 a las 9:58

  • Sin embargo, el problema con este enfoque de lista blanca es que la lista blanca puede crecer dependiendo de lo que las personas requieran en sus composer.jsonpor ejemplo, “ext-ldap” : “*”, o simplemente dependiendo de lo que se necesite para que las tareas posteriores a la instalación se ejecuten correctamente… Si tan solo hubiera una manera de incluir una extensión en la lista negra…

    – greg0ire

    27 de junio de 2015 a las 10:25

  • Intentaré hacer algo con la salida de php -m

    – greg0ire

    27 de junio de 2015 a las 10:27

  • Me viene a la mente, pero supongo que usas xdebug en un entorno de desarrollo. ¿El compositor es tan lento que necesita este ajuste?

    – Gui-Don

    27 de junio de 2015 a las 13:11


  • Oh no, acabo de ver esto de la salida de diagnosey ya que estoy construyendo contenedores docker de desarrollo para mi equipo, la más mínima mejora de velocidad podría beneficiar a todos

    – greg0ire

    27 de junio de 2015 a las 13:39

avatar de usuario
xserrat

Puede deshabilitar Xdebug configurando una variable de entorno:

XDEBUG_MODE=off composer install

Está disponible usando XDepuración 3.

avatar de usuario
adriano rosa

Al crear un alias, lo suprimirás composer xdebug mensaje de error.

Simplemente agregue esta línea a su ~/.bash_aliases dentro de su sistema y debería funcionar perfectamente.

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

Vuelva a cargar el shell para crear el nuevo alias composer disponible.

source ~/.bash_profile

USO:

$ composer --version

NOTA:
No necesariamente necesita usar ningún otro parámetro.
Dependiendo de su sistema, es posible que tenga un .bashrc en vez de .bash_profile.

ACTUALIZAR:

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

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

  • 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

    15/02/2016 a las 10:00

  • los -n opción deshabilita Phar extensión por lo que puede fallar al ejecutarse desde composer.phar

    – brzuchal

    6 oct 2016 a las 11:23

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

    – Alexander Kachkaev

    18/10/2016 a las 21:36

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

    – Enrique

    31 de octubre de 2016 a las 2:44

avatar de usuario
ezzatron

Se me ocurrió una respuesta que funciona bastante bien para OSX, y probablemente podría adaptarse a 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"

  • 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

    15/02/2016 a las 10:00

  • los -n opción deshabilita Phar extensión por lo que puede fallar al ejecutarse desde composer.phar

    – brzuchal

    6 oct 2016 a las 11:23

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

    – Alexander Kachkaev

    18/10/2016 a las 21:36

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

    – Enrique

    31 de octubre de 2016 a las 2:44

Normalmente creo un script de shell por proyecto, ya que cada proyecto tiene otra versión de PHP. esta en un /bin/ directorio junto a composer.phar y composer.json y lo ejecuto como ./bin/composer en mi directorio de proyectos.

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 "[email protected]"

los -d Las opciones deshabilitan efectivamente xdebug. los COMPOSER_DISABLE_XDEBUG_WARN=1 part desactiva 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 guión más simple.

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

Ejecutar con xdebug pero ini-deshabilitado: 0m19

Ejecutar sin xdebug: 0m10

  • Creo que dado que está deshabilitando XDebug, no necesita el COMPOSER_DISABLE_XDEBUG_WARN=1 : si recibe una advertencia, solo significa que su script no funciona. Definición xdebug.remote_autostart parece inútil si la depuración remota está deshabilitada.

    – greg0ire

    12 de enero de 2016 a las 16:43

  • tienes razón sobre xdebug.remote_autostart. Acerca de la efectividad de los scripts: Composer verifica si la extensión xdebug está cargada, no si realmente está haciendo algo mira el codigo aqui. Las opciones ini funcionan bien en los scripts php “normales”, pero de nuevo: no he realizado pruebas de rendimiento…

    – Joost

    13 de enero de 2016 a las 19:27


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

    – Joost

    13 de enero de 2016 a las 19:52

  • Hice algunos tiempos (en Mac OS X) y debo decir que estoy muy contento con las mejoras de rendimiento usando mi script. Con opciones de xdebug activado se necesita 1m33con las opciones desactivado se necesita 0m19. Sin la extensión xdebug se necesita 0m10.

    – Joost

    13 de enero de 2016 a las 22:07


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

    – greg0ire

    14 de enero de 2016 a las 9:18

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad