Xdebug runs for all cli commands despite remote_autostart being disabled











up vote
3
down vote

favorite
1












Without completely disabling Xdebug from the php.ini I'm currently unable to stop Xdebug from running for all cli commands. Previously I would toggle remote_autostart to enable if I needed to debug through cli. My problem is in particular causing issues with composer, effectively making it unrunnable. Composer claim that composer should restart without Xdebug running if they see it is running, this is supposedly fixed from composer version 1.3 forward, but I'm using composer 1.7.3.



This is running inside my alpine PHP-FPM docker container but that shouldn't really make a difference. This issue has previously been experienced by a co-worker inside vagrant too so I can get his environment details too if needed.



php.ini Xdebug settings which I set myself:



zend_extension=/var/www/html/xdebug/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.show_local_vars=0
xdebug.var_display_max_data=10000
xdebug.var_display_max_depth=20
xdebug.show_exception_trace=0
#xdebug.remote_autostart=1
xdebug.remote_host=172.20.0.1
xdebug.idekey="PHPSTORM"
xdebug.remote_log=/srv/www/var/log/xdebug.log


php -i | grep 'xdebug' output:



xdebug
xdebug support => enabled
xdebug.auto_trace => Off => Off
xdebug.cli_color => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => On => On
xdebug.collect_params => 0 => 0
xdebug.collect_return => Off => Off
xdebug.collect_vars => Off => Off
xdebug.coverage_enable => On => On
xdebug.default_enable => On => On
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.extended_info => On => On
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.gc_stats_enable => Off => Off
xdebug.gc_stats_output_dir => /tmp => /tmp
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => PHPSTORM => PHPSTORM
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.overload_var_dump => 2 => 2
xdebug.profiler_aggregate => Off => Off
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => /tmp => /tmp
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_addr_header => no value => no value
xdebug.remote_autostart => Off => Off
xdebug.remote_connect_back => Off => Off
xdebug.remote_cookie_expire_time => 3600 => 3600
xdebug.remote_enable => On => On
xdebug.remote_handler => dbgp => dbgp
xdebug.remote_host => 172.20.0.1 => 172.20.0.1
xdebug.remote_log => /srv/www/var/log/xdebug.log => /srv/www/var/log/xdebug.log
xdebug.remote_mode => req => req
xdebug.remote_port => 9000 => 9000
xdebug.remote_timeout => 200 => 200
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => Off => Off
xdebug.trace_enable_trigger => Off => Off
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => /tmp => /tmp
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 10000 => 10000
xdebug.var_display_max_depth => 20 => 20


Docker cli bash variables:



export XDEBUG_CONFIG="idekey=PHPSTORM";
export PHP_IDE_CONFIG="serverName=docker";


Xdebug log when making cli connection:



Log opened at 2018-11-08 10:53:30
I: Connecting to configured address/port: 172.20.0.1:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/
xdebug" fileuri="file:///srv/www/pi.php" language="PHP" xdebug:language_version
="7.1.23" protocol_version="1.0" appid="863" idekey="PHPSTORM"><engine version=
"2.6.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><
url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2
018 by Derick Rethans]]></copyright></init>









share|improve this question
























  • 1) If you set xdebug.remote_autostart=0, will it work? 2) Please check the actual config (e.g. php -i) to see actual values. Maybe that option is set & you have another partial config file that it is used... 3) Have composer and other tools use PHP with different php.ini (-c parameter (I believe)) or some other way around...
    – LazyOne
    Nov 8 at 15:20










  • Hi @LazyOne 1. xdebug.remote_autostart=0 makes no difference, and I've also checked my php_info() and confirmed that that is the default setting being used. 2. Yes I've checked php -i, good point though that I should use the full xdebug config from php.ini in my post, I'll update it after this comment. 3. If I'm going and creating/using a new php.ini just for composer I may as well just have an alias to disable xdebug, run composer, then enable xdebug instead, the issue here is that's just one use case. I have many data intensive cli commands which I run and I don't want to have to address...
    – George Appleton
    Nov 8 at 15:57










  • ... these use cases on an individual basis. It defeats the point. The issue here is that Xdebug is behaving incorrectly, workarounds are what I'm hoping to avoid. Thanks for your help
    – George Appleton
    Nov 8 at 15:58










  • I personally see nothing wrong in your php -i that could lead to debug session auto-startup. BTW -- what is /srv/www/pi.php file? Maybe it has some commands there that trigger xdebug session (e.g. xdebug_break(); or alike)... No better ideas from me, except trying to reinstall Xdebug again (you are using stable 2.6.1 and not unstable 2.7)
    – LazyOne
    Nov 8 at 16:56






  • 1




    @LazyOne found the reason, I'm going to try and fix it tomorrow, reason is at the bottom of this article larrykagan.com/xdebug-on-docker
    – George Appleton
    Nov 12 at 17:30

















up vote
3
down vote

favorite
1












Without completely disabling Xdebug from the php.ini I'm currently unable to stop Xdebug from running for all cli commands. Previously I would toggle remote_autostart to enable if I needed to debug through cli. My problem is in particular causing issues with composer, effectively making it unrunnable. Composer claim that composer should restart without Xdebug running if they see it is running, this is supposedly fixed from composer version 1.3 forward, but I'm using composer 1.7.3.



This is running inside my alpine PHP-FPM docker container but that shouldn't really make a difference. This issue has previously been experienced by a co-worker inside vagrant too so I can get his environment details too if needed.



php.ini Xdebug settings which I set myself:



zend_extension=/var/www/html/xdebug/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.show_local_vars=0
xdebug.var_display_max_data=10000
xdebug.var_display_max_depth=20
xdebug.show_exception_trace=0
#xdebug.remote_autostart=1
xdebug.remote_host=172.20.0.1
xdebug.idekey="PHPSTORM"
xdebug.remote_log=/srv/www/var/log/xdebug.log


php -i | grep 'xdebug' output:



xdebug
xdebug support => enabled
xdebug.auto_trace => Off => Off
xdebug.cli_color => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => On => On
xdebug.collect_params => 0 => 0
xdebug.collect_return => Off => Off
xdebug.collect_vars => Off => Off
xdebug.coverage_enable => On => On
xdebug.default_enable => On => On
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.extended_info => On => On
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.gc_stats_enable => Off => Off
xdebug.gc_stats_output_dir => /tmp => /tmp
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => PHPSTORM => PHPSTORM
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.overload_var_dump => 2 => 2
xdebug.profiler_aggregate => Off => Off
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => /tmp => /tmp
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_addr_header => no value => no value
xdebug.remote_autostart => Off => Off
xdebug.remote_connect_back => Off => Off
xdebug.remote_cookie_expire_time => 3600 => 3600
xdebug.remote_enable => On => On
xdebug.remote_handler => dbgp => dbgp
xdebug.remote_host => 172.20.0.1 => 172.20.0.1
xdebug.remote_log => /srv/www/var/log/xdebug.log => /srv/www/var/log/xdebug.log
xdebug.remote_mode => req => req
xdebug.remote_port => 9000 => 9000
xdebug.remote_timeout => 200 => 200
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => Off => Off
xdebug.trace_enable_trigger => Off => Off
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => /tmp => /tmp
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 10000 => 10000
xdebug.var_display_max_depth => 20 => 20


Docker cli bash variables:



export XDEBUG_CONFIG="idekey=PHPSTORM";
export PHP_IDE_CONFIG="serverName=docker";


Xdebug log when making cli connection:



Log opened at 2018-11-08 10:53:30
I: Connecting to configured address/port: 172.20.0.1:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/
xdebug" fileuri="file:///srv/www/pi.php" language="PHP" xdebug:language_version
="7.1.23" protocol_version="1.0" appid="863" idekey="PHPSTORM"><engine version=
"2.6.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><
url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2
018 by Derick Rethans]]></copyright></init>









share|improve this question
























  • 1) If you set xdebug.remote_autostart=0, will it work? 2) Please check the actual config (e.g. php -i) to see actual values. Maybe that option is set & you have another partial config file that it is used... 3) Have composer and other tools use PHP with different php.ini (-c parameter (I believe)) or some other way around...
    – LazyOne
    Nov 8 at 15:20










  • Hi @LazyOne 1. xdebug.remote_autostart=0 makes no difference, and I've also checked my php_info() and confirmed that that is the default setting being used. 2. Yes I've checked php -i, good point though that I should use the full xdebug config from php.ini in my post, I'll update it after this comment. 3. If I'm going and creating/using a new php.ini just for composer I may as well just have an alias to disable xdebug, run composer, then enable xdebug instead, the issue here is that's just one use case. I have many data intensive cli commands which I run and I don't want to have to address...
    – George Appleton
    Nov 8 at 15:57










  • ... these use cases on an individual basis. It defeats the point. The issue here is that Xdebug is behaving incorrectly, workarounds are what I'm hoping to avoid. Thanks for your help
    – George Appleton
    Nov 8 at 15:58










  • I personally see nothing wrong in your php -i that could lead to debug session auto-startup. BTW -- what is /srv/www/pi.php file? Maybe it has some commands there that trigger xdebug session (e.g. xdebug_break(); or alike)... No better ideas from me, except trying to reinstall Xdebug again (you are using stable 2.6.1 and not unstable 2.7)
    – LazyOne
    Nov 8 at 16:56






  • 1




    @LazyOne found the reason, I'm going to try and fix it tomorrow, reason is at the bottom of this article larrykagan.com/xdebug-on-docker
    – George Appleton
    Nov 12 at 17:30















up vote
3
down vote

favorite
1









up vote
3
down vote

favorite
1






1





Without completely disabling Xdebug from the php.ini I'm currently unable to stop Xdebug from running for all cli commands. Previously I would toggle remote_autostart to enable if I needed to debug through cli. My problem is in particular causing issues with composer, effectively making it unrunnable. Composer claim that composer should restart without Xdebug running if they see it is running, this is supposedly fixed from composer version 1.3 forward, but I'm using composer 1.7.3.



This is running inside my alpine PHP-FPM docker container but that shouldn't really make a difference. This issue has previously been experienced by a co-worker inside vagrant too so I can get his environment details too if needed.



php.ini Xdebug settings which I set myself:



zend_extension=/var/www/html/xdebug/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.show_local_vars=0
xdebug.var_display_max_data=10000
xdebug.var_display_max_depth=20
xdebug.show_exception_trace=0
#xdebug.remote_autostart=1
xdebug.remote_host=172.20.0.1
xdebug.idekey="PHPSTORM"
xdebug.remote_log=/srv/www/var/log/xdebug.log


php -i | grep 'xdebug' output:



xdebug
xdebug support => enabled
xdebug.auto_trace => Off => Off
xdebug.cli_color => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => On => On
xdebug.collect_params => 0 => 0
xdebug.collect_return => Off => Off
xdebug.collect_vars => Off => Off
xdebug.coverage_enable => On => On
xdebug.default_enable => On => On
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.extended_info => On => On
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.gc_stats_enable => Off => Off
xdebug.gc_stats_output_dir => /tmp => /tmp
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => PHPSTORM => PHPSTORM
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.overload_var_dump => 2 => 2
xdebug.profiler_aggregate => Off => Off
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => /tmp => /tmp
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_addr_header => no value => no value
xdebug.remote_autostart => Off => Off
xdebug.remote_connect_back => Off => Off
xdebug.remote_cookie_expire_time => 3600 => 3600
xdebug.remote_enable => On => On
xdebug.remote_handler => dbgp => dbgp
xdebug.remote_host => 172.20.0.1 => 172.20.0.1
xdebug.remote_log => /srv/www/var/log/xdebug.log => /srv/www/var/log/xdebug.log
xdebug.remote_mode => req => req
xdebug.remote_port => 9000 => 9000
xdebug.remote_timeout => 200 => 200
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => Off => Off
xdebug.trace_enable_trigger => Off => Off
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => /tmp => /tmp
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 10000 => 10000
xdebug.var_display_max_depth => 20 => 20


Docker cli bash variables:



export XDEBUG_CONFIG="idekey=PHPSTORM";
export PHP_IDE_CONFIG="serverName=docker";


Xdebug log when making cli connection:



Log opened at 2018-11-08 10:53:30
I: Connecting to configured address/port: 172.20.0.1:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/
xdebug" fileuri="file:///srv/www/pi.php" language="PHP" xdebug:language_version
="7.1.23" protocol_version="1.0" appid="863" idekey="PHPSTORM"><engine version=
"2.6.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><
url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2
018 by Derick Rethans]]></copyright></init>









share|improve this question















Without completely disabling Xdebug from the php.ini I'm currently unable to stop Xdebug from running for all cli commands. Previously I would toggle remote_autostart to enable if I needed to debug through cli. My problem is in particular causing issues with composer, effectively making it unrunnable. Composer claim that composer should restart without Xdebug running if they see it is running, this is supposedly fixed from composer version 1.3 forward, but I'm using composer 1.7.3.



This is running inside my alpine PHP-FPM docker container but that shouldn't really make a difference. This issue has previously been experienced by a co-worker inside vagrant too so I can get his environment details too if needed.



php.ini Xdebug settings which I set myself:



zend_extension=/var/www/html/xdebug/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.show_local_vars=0
xdebug.var_display_max_data=10000
xdebug.var_display_max_depth=20
xdebug.show_exception_trace=0
#xdebug.remote_autostart=1
xdebug.remote_host=172.20.0.1
xdebug.idekey="PHPSTORM"
xdebug.remote_log=/srv/www/var/log/xdebug.log


php -i | grep 'xdebug' output:



xdebug
xdebug support => enabled
xdebug.auto_trace => Off => Off
xdebug.cli_color => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => On => On
xdebug.collect_params => 0 => 0
xdebug.collect_return => Off => Off
xdebug.collect_vars => Off => Off
xdebug.coverage_enable => On => On
xdebug.default_enable => On => On
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.extended_info => On => On
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.gc_stats_enable => Off => Off
xdebug.gc_stats_output_dir => /tmp => /tmp
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => PHPSTORM => PHPSTORM
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.overload_var_dump => 2 => 2
xdebug.profiler_aggregate => Off => Off
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => /tmp => /tmp
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_addr_header => no value => no value
xdebug.remote_autostart => Off => Off
xdebug.remote_connect_back => Off => Off
xdebug.remote_cookie_expire_time => 3600 => 3600
xdebug.remote_enable => On => On
xdebug.remote_handler => dbgp => dbgp
xdebug.remote_host => 172.20.0.1 => 172.20.0.1
xdebug.remote_log => /srv/www/var/log/xdebug.log => /srv/www/var/log/xdebug.log
xdebug.remote_mode => req => req
xdebug.remote_port => 9000 => 9000
xdebug.remote_timeout => 200 => 200
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => Off => Off
xdebug.trace_enable_trigger => Off => Off
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => /tmp => /tmp
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 10000 => 10000
xdebug.var_display_max_depth => 20 => 20


Docker cli bash variables:



export XDEBUG_CONFIG="idekey=PHPSTORM";
export PHP_IDE_CONFIG="serverName=docker";


Xdebug log when making cli connection:



Log opened at 2018-11-08 10:53:30
I: Connecting to configured address/port: 172.20.0.1:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/
xdebug" fileuri="file:///srv/www/pi.php" language="PHP" xdebug:language_version
="7.1.23" protocol_version="1.0" appid="863" idekey="PHPSTORM"><engine version=
"2.6.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><
url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2
018 by Derick Rethans]]></copyright></init>






php docker composer-php xdebug






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 8 at 17:16

























asked Nov 8 at 11:04









George Appleton

536327




536327












  • 1) If you set xdebug.remote_autostart=0, will it work? 2) Please check the actual config (e.g. php -i) to see actual values. Maybe that option is set & you have another partial config file that it is used... 3) Have composer and other tools use PHP with different php.ini (-c parameter (I believe)) or some other way around...
    – LazyOne
    Nov 8 at 15:20










  • Hi @LazyOne 1. xdebug.remote_autostart=0 makes no difference, and I've also checked my php_info() and confirmed that that is the default setting being used. 2. Yes I've checked php -i, good point though that I should use the full xdebug config from php.ini in my post, I'll update it after this comment. 3. If I'm going and creating/using a new php.ini just for composer I may as well just have an alias to disable xdebug, run composer, then enable xdebug instead, the issue here is that's just one use case. I have many data intensive cli commands which I run and I don't want to have to address...
    – George Appleton
    Nov 8 at 15:57










  • ... these use cases on an individual basis. It defeats the point. The issue here is that Xdebug is behaving incorrectly, workarounds are what I'm hoping to avoid. Thanks for your help
    – George Appleton
    Nov 8 at 15:58










  • I personally see nothing wrong in your php -i that could lead to debug session auto-startup. BTW -- what is /srv/www/pi.php file? Maybe it has some commands there that trigger xdebug session (e.g. xdebug_break(); or alike)... No better ideas from me, except trying to reinstall Xdebug again (you are using stable 2.6.1 and not unstable 2.7)
    – LazyOne
    Nov 8 at 16:56






  • 1




    @LazyOne found the reason, I'm going to try and fix it tomorrow, reason is at the bottom of this article larrykagan.com/xdebug-on-docker
    – George Appleton
    Nov 12 at 17:30




















  • 1) If you set xdebug.remote_autostart=0, will it work? 2) Please check the actual config (e.g. php -i) to see actual values. Maybe that option is set & you have another partial config file that it is used... 3) Have composer and other tools use PHP with different php.ini (-c parameter (I believe)) or some other way around...
    – LazyOne
    Nov 8 at 15:20










  • Hi @LazyOne 1. xdebug.remote_autostart=0 makes no difference, and I've also checked my php_info() and confirmed that that is the default setting being used. 2. Yes I've checked php -i, good point though that I should use the full xdebug config from php.ini in my post, I'll update it after this comment. 3. If I'm going and creating/using a new php.ini just for composer I may as well just have an alias to disable xdebug, run composer, then enable xdebug instead, the issue here is that's just one use case. I have many data intensive cli commands which I run and I don't want to have to address...
    – George Appleton
    Nov 8 at 15:57










  • ... these use cases on an individual basis. It defeats the point. The issue here is that Xdebug is behaving incorrectly, workarounds are what I'm hoping to avoid. Thanks for your help
    – George Appleton
    Nov 8 at 15:58










  • I personally see nothing wrong in your php -i that could lead to debug session auto-startup. BTW -- what is /srv/www/pi.php file? Maybe it has some commands there that trigger xdebug session (e.g. xdebug_break(); or alike)... No better ideas from me, except trying to reinstall Xdebug again (you are using stable 2.6.1 and not unstable 2.7)
    – LazyOne
    Nov 8 at 16:56






  • 1




    @LazyOne found the reason, I'm going to try and fix it tomorrow, reason is at the bottom of this article larrykagan.com/xdebug-on-docker
    – George Appleton
    Nov 12 at 17:30


















1) If you set xdebug.remote_autostart=0, will it work? 2) Please check the actual config (e.g. php -i) to see actual values. Maybe that option is set & you have another partial config file that it is used... 3) Have composer and other tools use PHP with different php.ini (-c parameter (I believe)) or some other way around...
– LazyOne
Nov 8 at 15:20




1) If you set xdebug.remote_autostart=0, will it work? 2) Please check the actual config (e.g. php -i) to see actual values. Maybe that option is set & you have another partial config file that it is used... 3) Have composer and other tools use PHP with different php.ini (-c parameter (I believe)) or some other way around...
– LazyOne
Nov 8 at 15:20












Hi @LazyOne 1. xdebug.remote_autostart=0 makes no difference, and I've also checked my php_info() and confirmed that that is the default setting being used. 2. Yes I've checked php -i, good point though that I should use the full xdebug config from php.ini in my post, I'll update it after this comment. 3. If I'm going and creating/using a new php.ini just for composer I may as well just have an alias to disable xdebug, run composer, then enable xdebug instead, the issue here is that's just one use case. I have many data intensive cli commands which I run and I don't want to have to address...
– George Appleton
Nov 8 at 15:57




Hi @LazyOne 1. xdebug.remote_autostart=0 makes no difference, and I've also checked my php_info() and confirmed that that is the default setting being used. 2. Yes I've checked php -i, good point though that I should use the full xdebug config from php.ini in my post, I'll update it after this comment. 3. If I'm going and creating/using a new php.ini just for composer I may as well just have an alias to disable xdebug, run composer, then enable xdebug instead, the issue here is that's just one use case. I have many data intensive cli commands which I run and I don't want to have to address...
– George Appleton
Nov 8 at 15:57












... these use cases on an individual basis. It defeats the point. The issue here is that Xdebug is behaving incorrectly, workarounds are what I'm hoping to avoid. Thanks for your help
– George Appleton
Nov 8 at 15:58




... these use cases on an individual basis. It defeats the point. The issue here is that Xdebug is behaving incorrectly, workarounds are what I'm hoping to avoid. Thanks for your help
– George Appleton
Nov 8 at 15:58












I personally see nothing wrong in your php -i that could lead to debug session auto-startup. BTW -- what is /srv/www/pi.php file? Maybe it has some commands there that trigger xdebug session (e.g. xdebug_break(); or alike)... No better ideas from me, except trying to reinstall Xdebug again (you are using stable 2.6.1 and not unstable 2.7)
– LazyOne
Nov 8 at 16:56




I personally see nothing wrong in your php -i that could lead to debug session auto-startup. BTW -- what is /srv/www/pi.php file? Maybe it has some commands there that trigger xdebug session (e.g. xdebug_break(); or alike)... No better ideas from me, except trying to reinstall Xdebug again (you are using stable 2.6.1 and not unstable 2.7)
– LazyOne
Nov 8 at 16:56




1




1




@LazyOne found the reason, I'm going to try and fix it tomorrow, reason is at the bottom of this article larrykagan.com/xdebug-on-docker
– George Appleton
Nov 12 at 17:30






@LazyOne found the reason, I'm going to try and fix it tomorrow, reason is at the bottom of this article larrykagan.com/xdebug-on-docker
– George Appleton
Nov 12 at 17:30














1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










Undocumented Behavior



XDEBUG_CONFIG environment variable has the undesired effect of causing Xdebug to run on every execution as described at the bottom of this article. https://www.larrykagan.com/xdebug-on-docker/



For me the solution was just to stop using export XDEBUG_CONFIG="ide=PHPSTORM" as that setting is already in my ini anyway.






share|improve this answer





















    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53206443%2fxdebug-runs-for-all-cli-commands-despite-remote-autostart-being-disabled%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    1
    down vote



    accepted










    Undocumented Behavior



    XDEBUG_CONFIG environment variable has the undesired effect of causing Xdebug to run on every execution as described at the bottom of this article. https://www.larrykagan.com/xdebug-on-docker/



    For me the solution was just to stop using export XDEBUG_CONFIG="ide=PHPSTORM" as that setting is already in my ini anyway.






    share|improve this answer

























      up vote
      1
      down vote



      accepted










      Undocumented Behavior



      XDEBUG_CONFIG environment variable has the undesired effect of causing Xdebug to run on every execution as described at the bottom of this article. https://www.larrykagan.com/xdebug-on-docker/



      For me the solution was just to stop using export XDEBUG_CONFIG="ide=PHPSTORM" as that setting is already in my ini anyway.






      share|improve this answer























        up vote
        1
        down vote



        accepted







        up vote
        1
        down vote



        accepted






        Undocumented Behavior



        XDEBUG_CONFIG environment variable has the undesired effect of causing Xdebug to run on every execution as described at the bottom of this article. https://www.larrykagan.com/xdebug-on-docker/



        For me the solution was just to stop using export XDEBUG_CONFIG="ide=PHPSTORM" as that setting is already in my ini anyway.






        share|improve this answer












        Undocumented Behavior



        XDEBUG_CONFIG environment variable has the undesired effect of causing Xdebug to run on every execution as described at the bottom of this article. https://www.larrykagan.com/xdebug-on-docker/



        For me the solution was just to stop using export XDEBUG_CONFIG="ide=PHPSTORM" as that setting is already in my ini anyway.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 13 at 9:46









        George Appleton

        536327




        536327






























             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53206443%2fxdebug-runs-for-all-cli-commands-despite-remote-autostart-being-disabled%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            鏡平學校

            ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

            Why https connections are so slow when debugging (stepping over) in Java?