1

I have php5-fpm running on Raspberry Pi and serving the web site. I have installed php5-xdebug package and restarted php5-fpm and I hope have configured it for remote debug to 127.0.0.1:9000. I put server on 9000 to listen with nc -l 9000 command.

Unfortunately, when I open any page with http://mysite/mypage.php?XDEBUG_SESSION=1 nobody event try to connect to port 9000 as it seen by no characters in it's console. The page opens ok.

What else can prevent PHP debugger from work?


Attempts:

  1. Addition of xdebug.remote_log=/var/log/xdebug.log was indicated on phpinfo page, but had no effect: no any log was created, page was appeared instantly.

  2. Addition of xdebug_break(); at the beginning of php file also had no effect. No pauses, no logs.

  3. Changing of port didn't change anything...


My initial phpinfo was following:

Server API  FPM/FastCGI
Virtual Directory Support   disabled
Configuration File (php.ini) Path   /etc/php5/fpm
Loaded Configuration File   /etc/php5/fpm/php.ini
Scan this dir for additional .ini files /etc/php5/fpm/conf.d
Additional .ini files parsed    /etc/php5/fpm/conf.d/05-opcache.ini, /etc/php5/fpm/conf.d/10-pdo.ini, /etc/php5/fpm/conf.d/20-json.ini, /etc/php5/fpm/conf.d/20-readline.ini, /etc/php5/fpm/conf.d/20-xdebug.ini
PHP API 20131106
PHP Extension   20131226
Zend Extension  220131226
Zend Extension Build    API220131226,NTS
PHP Extension Build API20131226,NTS
Debug Build no
Thread Safety   disabled
Zend Signal Handling    disabled
Zend Memory Manager enabled
Zend Multibyte Support  provided by mbstring
IPv6 Support    enabled
DTrace Support  enabled
Registered PHP Streams  https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2
Registered Stream Filters   zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk
...
***
xdebug
xdebug support  enabled
Version 2.2.5
IDE Key www-data

***
Supported protocols Revision
DBGp - Common DeBuGger Protocol $Revision: 1.145 $
Directive   Local Value Master Value
xdebug.auto_trace   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.idekey   no value    no value
xdebug.max_nesting_level    100 100
xdebug.overload_var_dump    On  On
...
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  127.0.0.1   127.0.0.1
xdebug.remote_log   no value    no value
xdebug.remote_mode  req req
xdebug.remote_port  9000    9000
xdebug.scream   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
...
Dims
  • 47,675
  • 117
  • 331
  • 600
  • 1
    **1)** try setting `xdebug.remote_autostart=On` or add `xdebug_break();` in your PHP code. Right now it may not be enough for Xdebug to start debugging (`?XDEBUG_SESSION=1` may do .. but better try `XDEBUG_SESSION_START` param) **2)** Just in case: ensure that you are editing the right php.ini file as CLI and web server may use different configs .. so it;s better to get `phpinfo()` using the same way as trying to debug – LazyOne Dec 19 '20 at 14:15
  • 1
    **3)** Enable Xdebug log (`xdebug.remote_log`) and see what it will write there. **4)** Better use another port (e.g. `9001` or `9003` will do) -- the same TCP 9000 is often used by php-fpm for own needs (in such case Xdebug will be connecting to php-fpm instead of your VSCode -- Xdebug log can show that (based on the typical "go away" response)) – LazyOne Dec 19 '20 at 14:18
  • Just in case (as I'm a bit confused by your first paragraph): 1) Xdebug must connect to your debug client (VSCode as I understand) and not your web server. 2) It's Xdebug that connects to client and not other way around (the most common assumption/mistake) --- https://2.xdebug.org/docs/remote#communication 3) Xdebug port/host has nothing to do with website host/port. Especially port if it's on the same host -- it has to be different. – LazyOne Dec 19 '20 at 14:21
  • @LazyOne `nc -l 9000` is a socket server, it would print to console whatever was set by anybody connecting to port 9000, I was thinking it will indicate any attempt to connect, even unsuccessfull – Dims Dec 19 '20 at 14:31
  • I'm not Linux/networking expert so might be wrong .. but anyway. 1) Before doing that `nc -l 9000` -- check what app is listening on TCP 9000 port -- `netstat` shoudl do the job on Windows/Linux. MacOS has `lsof`. 2) If it's already busy (assuming that your VSCode or IDE is NOT running on that port) then IDE/VSCode will not be able to listen there.... – LazyOne Dec 19 '20 at 14:38
  • 1
    You understand 127.0.0.1 is localhost, regardless of which machine you're on? You must use your debugger machine's IP. – CodeCaster Dec 19 '20 at 14:38
  • @Dims 1) So it's a web page debug attempt, right? If so -- please show a screenshot of Xdebug section of `phpinfo()` captured via web page 2) What's your IDE and version (just to be sure -- only if it's NOT VSCode). 3) CodeCaster is right (I've missed that part completely) -- if the server is run on another device (Raspberry Pi) then the IP used in `xdebug_remote_host` has to point to the machine where debug client (IDE/editor) is running. 4) Xdebug log is needed. Without it it will be a lot of unnecessary and possibly wrong guessing. – LazyOne Dec 19 '20 at 14:43
  • @CodeCaster I was running `nc -l 9000` on the same machine – Dims Dec 19 '20 at 16:01
  • @LazyOne it started to work; I was only applying your recommendations and added reboot. Probably port change worked. Log file is still not creating. – Dims Dec 19 '20 at 16:02
  • @Dims If you have managed to make it working, please consider making an answer with your solution -- this will help other users in similar situation and having an accepted answer (which you can do later) makes this questions and solution more visible. – LazyOne Dec 21 '20 at 12:45

1 Answers1

1

I use xdebug 3. Here are a couple of points that may help others, which I missed initially:

  1. If the xdebug log is not created, make sure that log directory is accessible and writable by the apache user. For example /var/log is usually not, so it’s better to use /tmp/ like so:

    xdebug.log=/tmp/xdebug.log

  2. to enable xdebug you need to set the mode as well:

    xdebug.mode = debug

  3. My final xdebug section is below. You can change the client_port to apply to your case.

zend_extension="/usr/lib64/php/modules/xdebug.so"
xdebug.remote_enable=1
xdebug.remote_autostart=on
xdebug.client_port=9003
xdebug.log=/tmp/xdebug.log
xdebug.client_host=localhost
xdebug.discover_client_host = true
xdebug.mode = debug,develop
Aris
  • 4,643
  • 1
  • 41
  • 38