23

When working with Xdebug 3 in CLI, it constantly reports the message when there are no breakpoints set:

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

Is there a way to disable that message form showing in CLI?

LazyOne
  • 158,824
  • 45
  • 388
  • 391
Alexei Rayu
  • 406
  • 1
  • 4
  • 14
  • 2
    Could be your Xdebug settings. It does not print such stuff here. What are yours? Please show Xdebug section of `phpinfo()` or just `xdebug_info()`. – LazyOne Dec 09 '20 at 10:19
  • P.S. Similar question (in case if some updates will be posted there): https://stackoverflow.com/q/65162856/783119 – LazyOne Dec 09 '20 at 13:26
  • I do have xdebug.remote_autostart = yes - still, I would prefer that it does not show that message when it can't connect. Can't I disable that error message? – Alexei Rayu Dec 09 '20 at 13:41
  • 1
    I believe it's either one of the Xdebug settings or PHP itself. If you can provide your `phpinfo()` / `php -i` output I may compare with mine... as I do not see such warnings here when I do the same (I'm on Windows ... but I doubt it will make any difference here). Right now I believe it could be one of the `xdebug.XXX` options .. or perhaps how `error_log` is handled (because that's where such message gets normally written). – LazyOne Dec 09 '20 at 14:14
  • It's interesting how StackOverflow did not let me post my config, saying something like "Too much code, too little explanation." From your referenced answer I concluded you meant @xdebug.remote_autostart = yes@ - but funny how it probably built a ratio of code vs text and said too much code. – Alexei Rayu Dec 11 '20 at 10:08
  • 1
    Just in case: `xdebug.remote_autostart = yes` is Xdebug v2 option while Xdebug v3 uses `xdebug.start_with_request = yes` instead https://xdebug.org/docs/upgrade_guide. I've checked all options I could think of .. and could not locate the one that would force such entry to be printed in the normal output (except some sort of PHP's error log redirection .. as that's where such message normally goes). No better ideas from me (except perhaps checking Xdebug's Bug tracker for possible tickets) and therefore `xdebug.log_level = 0` sounds like a good solution here. – LazyOne Dec 11 '20 at 10:14
  • 1
    Check https://stackoverflow.com/a/65264131/783119 -- configure `error_log` setting properly. – LazyOne Dec 12 '20 at 12:09

7 Answers7

31

Unfortunately, the only way to disable this error is to disable generally ALL errors & warnings in xdebug.ini:

xdebug.log_level = 0

Hopefully there are other ways in future xdebug versions (imho this should only be a weak warning).

EDIT: As LazyOne mentioned, it's also possible to set an value for error_log in php.ini, for example /var/log/php_error.log. With that change, the log entries are written to this file and not sent to stderr.

Herbert Scheffknecht
  • 601
  • 5
  • 8
  • 2
    Xdebug should write such text into PHP error log ... and it does it here on Windows 10 (PHP 7.4 and 8.0 -- NTS build, x64). I do not see such warning here when doing my tests in terminal -- it arrives into the log ifle as it should (using default `xdebug.log_level` value, which is `7`). Perhaps it's some output redirection (error output stream or alike). – LazyOne Dec 09 '20 at 14:32
  • 2
    With `echo " – Herbert Scheffknecht Dec 10 '20 at 08:15
  • 1
    I understand that. It just I have no idea why it happens for you and does noting like that for me... Can you post your xdebug config (`xdebug_info()` output) -- you can redact IP/host name or other private parts (share it as a link). I'm interested to know why it happens. – LazyOne Dec 10 '20 at 09:19
  • This worked for me. My rationale is when I debug and the xdebug does not connect, it is pretty obvious to me - it does not stop at a breakpoint. Working with Drupal 8 and Drush, I get spammed with the warnings that it could not connect even if I simply don't set a breakpoint. – Alexei Rayu Dec 11 '20 at 10:04
  • @LazyOne: I only added xdebug.start_with_request=yes to control debugging only through PhpStorm without having the need for additional commands in CLI or browser extensions. Here is my xdebug_info() output: https://pastebin.com/VEqhQyQ1 – Herbert Scheffknecht Dec 11 '20 at 19:22
  • 3
    @haby What's the value of the `error_log` PHP settings. (e.g. from phpinfo(); output or just ini_get('error_log');). I believe it will be empty (or perhaps some incorrect location). If you set it to some proper location (e.g. something like `/var/log/php_error.log` or maybe even `/dev/null` - -depends n your OS and distro) then you should not see such error in the first place. Can you do that and check the same that you did in your first comment here? – LazyOne Dec 11 '20 at 19:41
  • 3
    You're right, it's empty. Setting it to the suggested filename and setting correct permissios, the error message disappear. I hadn't such behaviour with xdebug2, but thanks anyway. – Herbert Scheffknecht Dec 12 '20 at 07:22
  • 2
    @haby *"I hadn't such behaviour with xdebug2"* When Xdebug 3 sees that you are still using v2 params, it also notifies you about that using the same way. This is done on purpose to make user aware of "something might be wrong, you may want to look into it". – LazyOne Dec 12 '20 at 12:12
  • @LazyOne ahhhh , enlightened ... thks. Fixed it for me. – YvesLeBorg Sep 09 '21 at 14:36
  • Since v3.1 this answer is better option https://stackoverflow.com/a/71137245/12078462 – Anton Mikhalev Feb 16 '22 at 06:44
10

In my case the problem was that Xdebug tried to run on every request and since I didn't do debugging on every page refresh errors like Xdebug: [Step Debug] Could not connect to debugging client were reported and are understandable.

The most obvious solution with xdebug.log_level = 0 of course worked, but this was too broad and too blind way to fight this for me. So I checked the documentation, and the best way to get rid of that error in my opinion is to tell Xdebug when it should really run and when not, so the right option in my case is:

xdebug.start_with_request = trigger

as the documentation says:

The functionality only gets activated when a specific trigger is present when the request starts.

The name of the trigger is XDEBUG_TRIGGER, and Xdebug checks for its presence in either $_ENV (environment variable), $_GET or $_POST variable, or $_COOKIE (HTTP cookie name).

and I recommend checking at least that part of their docs because there's more info and you can even do more fine tuning if needed.

Picard
  • 3,745
  • 3
  • 41
  • 50
6

Starting from version 3.1, xdebug does not redirect its logs to php logs if you set the path to the log file. In my case, I use the following settings and these messages no longer dazzle the eyes in the console

xdebug.log=/var/www/var/log/xdebug.log
xdebug.log_level=3

PR for this issue: https://github.com/xdebug/xdebug/pull/738

Anton Mikhalev
  • 303
  • 3
  • 8
0

if you only need to suppress the output for one call you can use this - e.g. show version: XDEBUG_CONFIG="log_level=0" composer -v

Andreas Heissenberger
  • 728
  • 5
  • 8
0

Changing the php.ini 'xdebug.start_with_request' form 'yes' to 'trigger' solved my issue , I use MAMP.

xdebug.start_with_request = trigger
Super Kai - Kazuya Ito
  • 22,221
  • 10
  • 124
  • 129
user22084561
  • 1
  • 1
0

If you are running a PHP script or command you can set INI entry using -d:

php -d xdebug.log_level=0 your_sript.php
TiagoA
  • 229
  • 3
  • 13
-4

This is what you need:

xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.discover_client_host=1
FabianoLothor
  • 2,752
  • 4
  • 25
  • 39