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

            Schultheiß

            Verwaltungsgliederung Dänemarks

            Liste der Kulturdenkmale in Wilsdruff