Xdebug runs for all cli commands despite remote_autostart being disabled
up vote
3
down vote
favorite
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
|
show 6 more comments
up vote
3
down vote
favorite
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
1) If you setxdebug.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 yourphp -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
|
show 6 more comments
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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
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
php docker composer-php xdebug
edited Nov 8 at 17:16
asked Nov 8 at 11:04
George Appleton
595327
595327
1) If you setxdebug.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 yourphp -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
|
show 6 more comments
1) If you setxdebug.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 yourphp -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
|
show 6 more comments
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 13 at 9:46
George Appleton
595327
595327
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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