"XDebug could not open the remote debug file '/tmp/xdebug.log'."

[VladSavitsky]

Sorry, I don't want to collect debug info because there is a solution found already.

Problem

When xDebug enabled and run any drush command always get error messags:

XDebug could not open the remote debug file '/tmp/xdebug-remote.log'.

Reasons

/tmp/php5-xdebug.log not exists until you start debugging session in IDE and reload page in browser. Only then this file will be created.
When I enable xDebug and run any drush command (which is CLI) I got this error.

Solution

Source: geerlingguy/drupal-vm#1813
In Dockerfile you can append this to a RUN command

    # xdebug cannot write to it's log
    && touch /tmp/php-xdebug.log \
    && chown www-data:www-data /tmp/php-xdebug.log \
    && chmod 666 /tmp/php-xdebug.log

Could you please add this temp file creation to Dockerfile?

[csandanov]

Is this php5 issue? we no longer support php5

[VladSavitsky]

Sorry for this misunderstanding. I just copy-pasted code from other issue and didn't update it.
I'm using Docker4Drupal and php 7.1 and have this issue.

I know for sure that this file not exists at the very beginning because yesterday I troubleshot xdebug whole day...

[csandanov]

Try adding the env var PHP_XDEBUG_REMOTE_LOG: /proc/self/fd/2, does it change anything?

[VladSavitsky]

I added:

PHP_XDEBUG_REMOTE_LOG: /proc/self/fd/2

Ran drush cc all and got this output to console:

[130] Log opened at 2020-06-10 15:30:39
[130] I: Connecting to configured address/port: 172.17.0.1:9000.
[130] W: Creating socket for '172.17.0.1:9000', poll success, but error: Operation in progress (29).
[130] E: Could not connect to client. :-(
[130] Log closed at 2020-06-10 15:30:39
[130]
[134] Log opened at 2020-06-10 15:30:39
[134] I: Connecting to configured address/port: 172.17.0.1:9000.
[134] W: Creating socket for '172.17.0.1:9000', poll success, but error: Operation in progress (29).
[134] E: Could not connect to client. :-(
[134] Log closed at 2020-06-10 15:30:39
[134]
[134] Log opened at 2020-06-10 15:30:39
[134] I: Connecting to configured address/port: 172.17.0.1:9000.
[134] W: Creating socket for '172.17.0.1:9000', poll success, but error: Operation in progress (29).
[134] E: Could not connect to client. :-(
[134] Log closed at 2020-06-10 15:30:39
[134]
 'all' cache was cleared.                                               [success]

[pprishchepa]

@VladSavitsky as I see adding PHP_XDEBUG_REMOTE_LOG: /proc/self/fd/2 works as expected and you may get Xdebug logs from the output of PHP container.

Could you confirm that the pre-creating of /tmp/xdebug.log file is not relevant now?

[VladSavitsky]

No, it's not work as expected.
I have 2 modes:

1. Default (xDebug) disabled. All works fine. No problems.
2. xDebug enabled. Works but could be improved.

Adding PHP_XDEBUG_REMOTE_LOG: /proc/self/fd/2 cause log output for any drush call which is not expected. I don't need php-xdebug.log all the time. It's rearly used to debug xDebug configuration only. So this solves problem with missing log-file but outputs each time I call drush which is not desired.

Why empty file couldn't be created during container building? Is there some problems with it?
Maybe even better solution to redirect this log to /dev/null and update documentation so when someone needs this log he should enable it?!..

Thanks.

[pprishchepa]

You may enable PHP_XDEBUG_REMOTE_LOG when debugging Xdebug and then disable it. In this case, the mixing of application and Xdebug logs in a container output will not be a big problem, because it is a pretty rare case.

I agree that Xdebug debugging should be documented because it is not obvious now.

Why empty file couldn't be created during container building?

In the case of docker containers, all logs must be streamed to a container output instead of a file where it is possible.

[VladSavitsky]

I can't test it right now. What is default value for PHP_XDEBUG_REMOTE_LOG?
Will this log file be created even if I remove (comment out) PHP_XDEBUG_REMOTE_LOG and enable xDebug? If not then solution could be simply uncomment this option only when it's really necessary and keep it commented when no need to debug xDebug.
Thanks.

[pprishchepa]

The setting PHP_XDEBUG_REMOTE_LOG is empty by default.

Once you need debugging Xdebug you may add this environment variable PHP_XDEBUG_REMOTE_LOG: /proc/self/fd/2

/proc/self/fd/2 value means that Xdebug logs will be written to a container output, so no special files required.

I tested it by running this command:
docker run --rm -it -e PHP_XDEBUG=1 -e PHP_XDEBUG_REMOTE_LOG=/proc/self/fd/2 wodby/php:7.4 php -r "print 'foo';"

You may see Xdebug remote logs in the output:

[1] Log opened at 2020-06-18 14:27:54
[1] I: Checking remote connect back address.
[1] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[1] I: Checking header 'REMOTE_ADDR'.
[1] W: Remote address not found, connecting to configured address/port: localhost:9000. :-|
[1] W: Creating socket for 'localhost:9000', poll success, but error: Operation in progress (29).
[1] W: Creating socket for 'localhost:9000', connect: Address not available.
[1] E: Could not connect to client. :-(
[1] Log closed at 2020-06-18 14:27:54

[VladSavitsky]

I believe this information could be useful for others and docs should be updated.
Especially empty default value of this setting. So it should be only set for debugging xDebug and not for regular work.
I could confirm that PHP_XDEBUG_REMOTE_LOG=/proc/self/fd/2 outputs to strout.
Also I didn't know that it not good practice to create file insite container. This I think also nice to have in documentation.

Thanks.

[mxr576]

With the current Xdebug configuration I can see notices like this:
NOTICE: PHP message: Xdebug: [Log Files] File '/proc/self/fd/2' could not be opened.

Could be related to docker-library/php#358 (comment)

[Dids]

With the current Xdebug configuration I can see notices like this:
NOTICE: PHP message: Xdebug: [Log Files] File '/proc/self/fd/2' could not be opened.

Could be related to docker-library/php#358 (comment)

Did you ever find a fix for this? Seeing this too, and while everything else works fine with /proc/self/fd/2 logging, Xdebug 3 doesn't seem to be working at all, which produces the notice.