Random 502 Bad Gateway errors when Xdebug is enabled

[esequielp]

Description

I am using the last installation :

curl -s https://raw.githubusercontent.com/markshust/docker-magento/master/lib/onelinesetup | bash -s -- magento.test 2.4.6-p4 community

Error happens when go to especify product

Steps To Reproduce

1. go to , https://magento.test/women/tops-women.html , then choose a especify product

Expected Result

open the product

Actual Result
give 502 Bad Gateway

[esequielp]

This is my SO

[YevhenZvieriev]

Hi, @esequielp

Did you change Nginx conf?
You should check the log files.

[esequielp]

NO , I didnt change the nginx config, where I can see the logs files?

[YevhenZvieriev]

To see the log files you can execute the bin/log script.

And the error log is at within the Docker container:
/var/log/nginx/error.log

What is the Nginx image you use?

I can't reproduce this issue.
I installed Magento v2.4.6-p4, and deployed sample data, and it works for me.

You didn't have a problem during the bin/magento sampledata:deploy command?

To be sure try to execute these commands:

bin/fixowns
bin/fixperms
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy
bin/magento cache:flush

[giangvdm]

I also encounter this 502 error when randomly refresh the page while having Xdebug enabled.

Logs from Nginx says: recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 172.24.0.1, server: , request: "GET /customer/account/login/referer/aHR0cHM6Ly95b3VibG9iLmxvY2FsLw~~/ HTTP/2.0", upstream: "fastcgi://unix:/sock/docker.sock:", host: "youblob.local", referrer: "https://my.domain/"

If Xdebug is disabled, no error occurs.

[derekBaldwinGG]

When I enable xdebug, sometimes it works, sometimes it throws the 502 error. I can set breakpoints and it breaks as expected when it works, but half the time it throws a 502.

I'm using the latest docker-magento setup on a macbook with an m3 chip, with an existing project.

Here is my app log error:
2024/03/22 22:25:18 [info] 30#30: *81 client 127.0.0.1 closed keepalive connection 2024/03/22 22:25:32 [error] 30#30: *55 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.228.1, server: , request: "POST /company/account/createPost/ HTTP/2.0", upstream: "fastcgi://unix:/sock/docker.sock:", host: "magento.test", referrer: "https://magento.test/company/account/create/"

Here is my phpfpm related error:
child 64 exited on signal 11 (SIGSEGV)

Any ideas? I'm not a server admin. Thanks for the help!

[madmytrych]

I often get 502 error when xdebug is enabled too.
There are logs:

2024-03-29 12:43:45 [29-Mar-2024 10:43:45] WARNING: [pool www] child 58 said into stderr: "Fri Mar 29 10:43:45 2024 (58): [Error] APM: Locking APM for 300 seconds for reason: Cannot connect to the agent"
2024-03-29 12:43:45 [29-Mar-2024 10:43:45] WARNING: [pool www] child 59 said into stderr: "Fri Mar 29 10:43:45 2024 (59): [Error] APM: Locking APM for 300 seconds for reason: Cannot connect to the agent"
2024-03-29 12:43:45 [29-Mar-2024 10:43:45] WARNING: [pool www] child 56 exited on signal 11 (SIGSEGV) after 5.021329 seconds from start
2024-03-29 12:43:45 [29-Mar-2024 10:43:45] NOTICE: [pool www] child 61 started
2024-03-29 12:43:46 - -  29/Mar/2024:10:43:46 +0000 "GET /index.php" 200
2024-03-29 12:43:46 [29-Mar-2024 10:43:46] WARNING: [pool www] child 60 said into stderr: "Fri Mar 29 10:43:46 2024 (60): [Error] APM: Locking APM for 300 seconds for reason: Cannot connect to the agent"
2024-03-29 12:44:04 [29-Mar-2024 10:44:04] WARNING: [pool www] child 57 exited on signal 11 (SIGSEGV) after 23.507697 seconds from start
2024-03-29 12:44:04 [29-Mar-2024 10:44:04] NOTICE: [pool www] child 62 started

P.S.
I fixed it by downgrading xdebug:
compose.yaml changes(comment 'image' and add 'build'):

....
phpfpm:
#    image: markoshust/magento-php:8.1-fpm-2
    volumes: *appvolumes
    env_file: env/phpfpm.env
    build:
      context: .
      dockerfile: containers/phpfpm/Dockerfile # your custom file

containers/phpfpm/Dockerfile contains:

FROM markoshust/magento-php:8.1-fpm-2
USER root
RUN pecl uninstall xdebug
RUN pecl install xdebug-3.1.0 && docker-php-ext-enable xdebug
USER app:app

Remove your phpfpm and rebuild
I'm not sure if this customization is docker-style correct, but it works

[CarlosM-ESP]

Same problem with 502 bag gateway.
Cannot use the modified xdebug downgrade. found this error:
Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.2.0". You are running 8.1.27. in /var/www/html/vendor/composer/platform_check.php on line 24

Tried to use a different php-fpm instance but it ddn't work
FROM markoshust/magento-php:8.1-fpm-2

[madmytrych]

Hello @CarlosM-ESP , I've provided the example from my local environment. In your case, you could experiment with different combinations of PHP(use your current version) and different Xdebug versions. It seems that there may be compatibility issues between specific versions of PHP and Xdebug

[CarlosM-ESP]

@markshust
Good Morning, Mark. Does the new release of docker-magento for M2.4.7 corrects this issue?
Regards.

[markshust]

@CarlosM-ESP I'm looking into this further. I'm thinking the SPX extension that was added in a couple months ago could potentially be conflicting with Xdebug.

Also... https://bugs.xdebug.org/view.php?id=2253

I'm wondering if we should downgrade to the last major version release of Xdebug (3.2.2).

[markshust]

I've replicated the issue, and have confirmed that the Xdebug is causing it.

[markshust]

I have confirmed that a "502 Bad Gateway" error is always returned and replicable whenever Xdebug 3.3.1 is enabled (per bug filed at https://bugs.xdebug.org/view.php?id=2253).

The issue is resolved by downgrading Xdebug back to 3.2.2. While this works for PHP 8.1/8.2, unfortunately it is not an option when running PHP 8.3 due to package version constraints (pecl/xdebug requires PHP (version >= 8.0.0, version <= 8.2.99), installed version is 8.3.6).

I'll update the PHP 8.1/8.2 images to downgrade Xdebug back to 3.2.2. I'll have this updated tomorrow.

Unfortunately, there is no resolution for PHP 8.3 due to hard version constraints set by Xdebug.

I'm surprised others aren't commenting on the Xdebug bug/issue as running Xdebug on PHP 8.3 is currently not an option. If you'd like this fixed for PHP 8.3, I'd recommend to comment on the ticket at https://bugs.xdebug.org/view.php?id=2253 to increase the likelihood of this bug getting resolved.

[markshust]

Another possibly related bug before I build & tag new images, related to running Blackfire and Xdebug at the same time: https://bugs.xdebug.org/view.php?id=2230

Few possible resolutions/options:

1. It may be possible to circumvent this issue, as noted, by ensuring Blackfire is loaded before Xdebug. I'm not entirely sure how to do this.
2. A fix for this has already been merged into 3.3dev, but it's not yet released: https://bugs.xdebug.org/changelog_page.php. I'm not sure if we can monkey-patch this diff on top of 3.3.1, or if there is a way to install the 3.3dev version with pecl.
3. I haven't confirmed this is the issue yet, but if it is, we could also simply disable Blackfire by default.

[markshust]

FYI I don't think changing the load order of extensions is possible, as the ini files are loaded alphabetically, and it seems as though blackfire is already loading before xdebug:

app@cc351baed70e:/usr/local/lib/php$ vi /usr/local/etc/php/conf.d/
blackfire.ini                 docker-php-ext-exif.ini       docker-php-ext-mysqli.ini     docker-php-ext-soap.ini       docker-php-ext-sysvsem.ini    spx.ini
docker-fpm.ini                docker-php-ext-gd.ini         docker-php-ext-opcache.ini    docker-php-ext-sockets.ini    docker-php-ext-sysvshm.ini    
docker-php-ext-bcmath.ini     docker-php-ext-gettext.ini    docker-php-ext-pcntl.ini      docker-php-ext-sodium.ini     docker-php-ext-xdebug.ini     
docker-php-ext-bz2.ini        docker-php-ext-imagick.ini    docker-php-ext-pdo_mysql.ini  docker-php-ext-ssh2.ini       docker-php-ext-xsl.ini        
docker-php-ext-calendar.ini   docker-php-ext-intl.ini       docker-php-ext-redis.ini      docker-php-ext-sysvmsg.ini    docker-php-ext-zip.ini   

But this is not representative of the output, as it looks like it is loading after xdebug:

app@cc351baed70e:/usr/local/lib/php$ php -v
PHP 8.2.18 (cli) (built: Apr 11 2024 19:28:30) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.18, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.18, Copyright (c), by Zend Technologies
    with Xdebug v3.2.2, Copyright (c) 2002-2023, by Derick Rethans
    with blackfire v1.92.13~linux-x64-non_zts82, https://blackfire.io, by Blackfire

If the output is unrelated, this means that Blackfire is probably loading first, and that issue or possible fix is not applicable. It's getting late here, but I'll look more into this tomorrow.

[esequielp]

Thanks @markshust Please inform when you resolve this issue!

[markshust]

I've confirmed that this issue of Xdebug conflicting with the Blackfire extension is the most likely culprit of this bug, as Xdebug 3.3.1 works with PHP 8.3 if the Blackfire extension is disabled.

Here's how I'll proceed:

1. Revert PHP 8.1 and 8.2 images to use Xdebug 3.2.2, as both Xdebug and Blackfire work at the same time on this version.
2. Since PHP 8.3 requires Xdebug 3.3 or higher, we will keep Xdebug at 3.3.1, but disable Blackfire by default, as it's not nearly as widely used as Xdebug.
3. Because of this, I created a new bin/blackfire script to easily enable or disable Blackfire (New bin/blackfire script to enable, disable, or check status of Blackfire extension #1115). This will allow those who wish to use Blackfire to easily enable it on PHP 8.3, but note that until the above Xdebug bug is resolved, you cannot run Xdebug at the same time as Blackfire. I'll add this to the README as a "known issue".

The code is about ready to go, but I will need GitHub actions to recompile the new images. This process typically takes about 90 minutes once it starts, so I'll check back later to update the compose.yaml file to the new image version once it's complete, and tag this update as 46.1.0.

This version will also contain the PHP Swoole extension for Adobe Commerce GraphQL Application Layer support (#1114). I haven't delved into this topic yet to find out how to configure it with Commerce or run the application layer, but we'll need this extension anyways for this app layer, so I figured I'd build this in since we'll need new images anyways (I forgot to add it in the initial PHP 8.3 image at the time of the Magento 2.4.7 release earlier this week).

I'll update this ticket as soon as the new images and configuration has been published.

[markshust]

It looks like GitHub auto-closed this ticket, but it should be resolved.

The images are being re-built right now (https://github.com/markshust/docker-magento/actions). I'll tag docker-magento 46.1.0 when they have completed building.

[markshust]

This issue should now be resolved, as docker-magento 46.1.0 has been released (#1119).

I created a subsequent ticket about Xdebug 3.3 and Blackfire incompatibility at #1118 which you can watch for future updates.

[CarlosM-ESP]

@markshust
Thank you Mark for your dedication!

[CarlosM-ESP]

Magento 2.4.7 installed. Xdebug problem disappeared. Thank you, Mark!

[nellodb]

Thanks for the update.
I'm on a MacOS Intel and I was experiencing the random 502s aswell, ran a bin/update which brought the docker's phpfpm to 8.3-fpm-2.
The random 502s were fixed but even though I had disabled blackfire and enabled XDebug the environment pretty much ran to a halt with php-fpm constantly maxed-out at a hundred percentage and a huge CPU load.

I've downgraded to

    image: markoshust/magento-php:8.2-fpm-4

which at the moment seems to run just fine. Not sure where the issue lies, just commented out of curiosity to check if anyone ran into the same issue.