2

I am trying to convert my recent XAMPP development setup to a LAMP stack based on WSL2.

So far I've been successful. I can access my testpage test.php containing <?php phpinfo(); via https://localhost/test.php (using a self-signed certificate for dev-purposes.)

Sadly, I'm completely stuck at getting Xdebug to work.

Xdebug: [Step Debug] Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port) :-(

I have been going through these threads already, but to no avail:

My setup:

  • Windows 10 with WSL2 installed
  • Ubuntu 20.04 with Apache2
  • PHP 8.0.5 with Xdebug 3.0.4
  • PhpStorm (IDE)

My Xdebug settings at /etc/php/8.0/apache2/php.ini:

[xdebug]
xdebug.mode=debug
xdebug.remote_port=9003
xdebug.client_port=9003
xdebug.start_with_request=yes
xdebug.remote_host=localhost
xdebug.idekey=PHPSTORM
xdebug.discover_client_host=1

;xdebug.client_host=localhost
;xdebug.remote_enable=1
;xdebug.remote_handler=dbgp

I have tried commenting "discover_client" and explicitly setting the client host to localhost. No change.

The output of phpinfo() seems to indicate that these settings are not ignored. See screenshot of the relevant parts.

The relevant settings for the virtual host in /etc/apache2/sites-available/default-ssl.conf are:

<VirtualHost: *:443>
    ServerName localhost
    DocumentRoot "/mnt/d/projects/testproject/public"
    <Directory "/mnt/d/projects/testproject/public/">
        Options +Indexes +Includes +FollowSymlinks +MultiViews
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

(The "all granted" is only temporary while debugging)

I don't know if this is relevant, but I made sure that C:\Windows\System32\drivers\etc\hosts contains

127.0.0.1 localhost
::1 localhost

So when I run

php -dxdebug.mode=debug /mnt/d/projects/testproject/public/test.php

I get

Xdebug: [Step Debug] Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port) :-(

Does anyone see the problem? Or can anyone give me a hint on where to look next?

hakre
  • 193,403
  • 52
  • 435
  • 836
fridde
  • 472
  • 1
  • 5
  • 17
  • Are you running the xdebug client under WSL2 as well? Which xdebug client are you using? Where do you run your xdebug client? / maybe this helps? https://superuser.com/q/1586386/63279 – hakre Jul 03 '21 at 11:33
  • Thanks for looking into this! I wasn't really aware of the client/server structure of xdebug itself, I had always been lucky that things just worked. I checked xdebug.org and downloaded the Simple DBGp client 0.4.2 and ran it on my test.php. I got "Waiting for debug server to connect on port 9003" and when I visited "localhost/test.php" in my browser my terminal showed a connection while the browser waited. So at least something. – fridde Jul 03 '21 at 13:23
  • Cool, so actually, when you say "it just worked", what were you using back then? You may not have called it client but something else (that then was acting as the debug client), like _editor_, _debugger_, _IDE_. Which one? And I guess you want to keep using that one, right? – hakre Jul 03 '21 at 13:27
  • Yes, I am using PhpStorm. I am using the validation tool and it was the one throwing the error initially. The validation script simply creates some file "_intellij_php_validator.php" and tries to run it using the CLI. I tried to isolate the problem and ran the same command directly in my terminal. – fridde Jul 03 '21 at 14:14
  • @friddle: Please check with the PhpStorm docs if WSL2 is supported for debugging (and executing PHP first hand). In any case, xdebug needs to connect from WSL2 (Linux) to Phpstorm (Windows) and networking must work vice versa. Phpstorm normally waits for the connections to come in, so xdebug within WSL2 needs to know to which address to connect to (the IP address). I have no WSL2 here for testing, but all in all it should be just the networking, your test with the simple dbgp client showed you already that it basically works. – hakre Jul 03 '21 at 14:22
  • Hmm, `xdebug.discover_client_host=1` should have worked I think. Are you testing with the browser from Windows (where also Phpstorm runs)? While trouble-shooting, explicitly setting [xdebug.client_host](https://xdebug.org/docs/all_settings#client_host) to the correct value may help in case request header detection does not work. – hakre Jul 03 '21 at 14:35
  • After some more work I got yet another partial success: using https://www.silverf0x00.com/setting-up-xdebug-for-phpstorm-on-windows-wsl2/ as a guide, I edited the host file to the "actual" IP (like 172.17.1.12) and then configured everything as a remote and not local. Now I can visit localhost and PhpStorm stops at the breakpoint! Hooray! Sadly, there are still a lot of issues and I will probably wait a year until WSL, xdebug and PhpStorm work better together. – fridde Jul 03 '21 at 20:11
  • Congrats. It's perhaps worth to draft an answer out of it. WSL is pretty new, not even a decade old. – hakre Jul 03 '21 at 20:50

1 Answers1

1

The option xdebug.start_with_request = yes tells Xdebug to try to debug every single request/script. If Xdebug fails to connect to the debug client (it takes values from xdebug.client_host and xdebug.client_port, or autodetected host if xdebug.discover_client_host is enabled) then it notifies you about that.

Normally such a messages will be written to the standard PHP's error log. Looks like you don't have it configured at all in your php.ini (as this is how it comes by default), therefore PHP sends it to your standard output instead.

If you want to prevent it from appearing on you terminal output you have to point the PHP error_log to a valid location.

Example of how I solved it in my case:

1- Edit your ini file:

sudo vi /etc/php/7.4/cli/php.ini

2- And add this line:

error_log = /var/www/log/php_error.log

NOTE: Change the previous routes to any valid directory you want.

3- Try again and the warning should disappear and now goes to the log file.

Adriana Hernández
  • 799
  • 9
  • 23
  • Removing `xdebug.start_with_request` solved it for me. – Code Spirit Mar 03 '23 at 15:08
  • The problem was not that there was an error message which should be hidden. The goal was to get rid of the error message by solving the issue and connecting to the debugging client. – Csongor Halmai Jul 08 '23 at 15:08