• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved 502 Bad Gateway after upgrade to Obsidian 18.0.40

Kulturmensch

Regular Pleskian
After the upgrade to Plesk Obsidian 18.0.40 (Plesk Obsidian v18.0.40_build1800211119.12 os_Ubuntu 20.04) I get the 502 Bad Gateway Error
after hanging a metatag in Drupal (9) and returning to the Website.

Protocol shows the following:

My-IP6 .... 16036#0: *10325 recv() failed (104: Connection reset by peer) while reading response header from upstream ... nginx-error

No plesk-repair attempt solve this. The website remains unreachable (502).

After replacing all Drupl-files including the DB with a backup everything works again like usual until I try to change something in the Drupal-Konfiguration.
 
The script or configuration of the website is causing this error. Check the Apache logs (not the Nginx logs) to find out more what the script does and why it fails to respond to Nginx.
 
Thank you. I checked the Apache logs. There where nothing helpful. Probably because I use nginx not as proxy but stand alone.
In an other subdomain I get now the same errors errors after modifying the drupal metatags:
2021-11-28 19:35:50Error2003:f7:bf15:2800:9502:a0b7:5fd2:b868502GET / HTTP/1.1
https://mirror.tenckhoff.de/user/1
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0
830 SSL/TLS-Zugriff für nginx
2021-11-28 19:35:50Error2003:f7:bf15:2800:9502:a0b7:5fd2:b868404GET /favicon.ico HTTP/1.1
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0
468 SSL/TLS-Zugriff für nginx
2021-11-28 19:35:50Error2003:f7:bf15:2800:9502:a0b7:5fd2:b868135461#0: *939 recv() failed (104: Connection reset by peer) while reading response header from upstreamnginx-Fehler
 
It can't be standalone, because it is expecting a response from "upstream", which is the server it connects to (Apache).
 
In PHP have you selected PHP via Nginx or is there still a PHP via Apache configuration active? Have you tried to reconfigure the website, e.g. plesk repair domain <domainname>?
 
And
root@mail:~# plesk repair web

Checking the configuration of Apache modules ........................ [OK]

Checking web server configuration

Reinstall SSL/TLS certificates and set the default certificate for all IP addr esses? [Y/n] Y
Reinstalling SSL/TLS certificates ............................... [OK]
Applying the default SSL/TLS certificate to all IP addresses .... [OK]

Repair web server configuration for all domains? [Y/n] Y
Repairing web server configuration for all domains. This aspect
can be used with individual domains ("plesk repair web
example.com"), and on the server level ("plesk repair web") ..... [OK]

Repair server-wide configuration parameters for web servers? [Y/n] Y
Repairing server-wide configuration parameters for web servers .. [OK]

Checking the usage of PHP handlers .................................. [OK]

Checking for obsolete PHP-FPM configuration files ................... [OK]

Error messages: 0; Warnings: 0; Errors resolved: 0

root@mail:~#
 
Drupal has a module called metatag. If I switch in extended settings the language from "de" to "de_DE", save this and go to the homepage then I receive this error. I f I write a new article, save it and go to the homepage everything works fine. It is very confusing.
 
Could it be possible that your website is using a cache that needs to be rebuilt after a change? Maybe rebuilding the cache takes too much time so that a timeout is reached and no response is sent to the webserver in time.
 
I am using the php-extension "drush" to manage my drupal site and with the drush command "drush cr" the cache is rebuild. But this did not solve my problem which still persist.
Do you know a safe procedure to fall back to the previous Plesk-Version - in my case 18.0.39 update 2? With this version everything worked fine for me. I have also new problems with the Plesk-backup (I opened a further issue describing this) and lost confidence in the 18.0.40-Version of Plesk.
 
A Plesk downgrade is not possible.

It is highly likely that the cause is not the update, but something in the sites themselves. We are not seeing anything alike on any of our servers here, and the number of users is so high that we should have seen issues if there are basic issues with the latest Plesk version.

Are you using webserver rewrite rules? Has anything changed with the hosting settings www/non-www or SSL/non-SSL? Are the sites consistently using the exact same URL throughout each session? Are they waiting on external input? There has got to be a factor that keeps the site from responding. Could it be an incompatibility with the latest PHP version?
 
First of all - let me record my thank for your appreciate advice!!

I just tested another php-Version (7 instead 8) and followed you last recommendation by adding
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
to the nginx-configuration.
Then I startet the plesk repair installation and later plesk repair all via ssh. The result was "success" but it did not solve my problem.

During this repair procedure I got the following warnings:

WARNING:Skip fixing 'php-ioncube-loader': Cannot find deb-archive for package php-ioncube-loader (10.4.5-v.ubuntu.20.04+p18.0.35.0+t210311.0 745)
WARNING:Skip fixing 'plesk-libboost-1.65': Cannot find deb-archive for package plesk-libboost-1.65 (1.65.1-ubuntu.20.04.200630.1129)
WARNING:Skip fixing 'plesk-libboost-chrono1.65': Cannot find deb-archive for package plesk-libboost-chrono1.65 (1.65.1-ubuntu.20.04.200630.1 129)
WARNING:Skip fixing 'plesk-libboost-date-time1.65': Cannot find deb-archive for package plesk-libboost-date-time1.65 (1.65.1-ubuntu.20.04.20 0630.1129)
WARNING:Skip fixing 'plesk-libboost-filesystem1.65': Cannot find deb-archive for package plesk-libboost-filesystem1.65 (1.65.1-ubuntu.20.04. 200630.1129)
WARNING:Skip fixing 'plesk-libboost-iostreams1.65': Cannot find deb-archive for package plesk-libboost-iostreams1.65 (1.65.1-ubuntu.20.04.20 0630.1129)
WARNING:Skip fixing 'plesk-libboost-locale1.65': Cannot find deb-archive for package plesk-libboost-locale1.65 (1.65.1-ubuntu.20.04.200630.1 129)
WARNING:Skip fixing 'plesk-libboost-program-options1.65': Cannot find deb-archive for package plesk-libboost-program-options1.65 (1.65.1-ubu ntu.20.04.200630.1129)
WARNING:Skip fixing 'plesk-libboost-regex1.65': Cannot find deb-archive for package plesk-libboost-regex1.65 (1.65.1-ubuntu.20.04.200630.112 9)
WARNING:Skip fixing 'plesk-libboost-serialization1.65': Cannot find deb-archive for package plesk-libboost-serialization1.65 (1.65.1-ubuntu. 20.04.200630.1129)
WARNING:Skip fixing 'plesk-libboost-system1.65': Cannot find deb-archive for package plesk-libboost-system1.65 (1.65.1-ubuntu.20.04.200630.1 129)
WARNING:Skip fixing 'plesk-libboost-thread1.65': Cannot find deb-archive for package plesk-libboost-thread1.65 (1.65.1-ubuntu.20.04.200630.1 129)
WARNING:Skip fixing 'plesk-libpoco-1.9.0': Cannot find deb-archive for package plesk-libpoco-1.9.0 (1.9.0-ubuntu.20.04.200703.1727)
WARNING:Skip fixing 'plesk-libstdc++6.3.0': Cannot find deb-archive for package plesk-libstdc++6.3.0 (6.3.0-ubuntu.20.04.200630.1040)
WARNING:Skip fixing 'pp18.0.38-bootstrapper': Cannot find deb-archive for package pp18.0.38-bootstrapper (18.0-v.ubuntu.20.04+p18.0.38.3+t21 1001.1903)
WARNING:Skip fixing 'sw-engine-cli-3.38': Cannot find deb-archive for package sw-engine-cli-3.38 (3.38.0-ubuntu.20.04.210809.1937)
WARNING:Skip fixing 'sw-engine-cli-3.39': Cannot find deb-archive for package sw-engine-cli-3.39 (3.39.1-ubuntu.20.04.210924.1832)


Do you know, whether these warning would belong to my "502 Bad Gateway" problem (or to my Backup-problem)?
 
It may or may not be linked, but I do not know. It is a new issue, obviously on Ubuntu servers only.

I believe that there is an issue with the websites themselves, because you say that the current version works while the websites quit working after an update. An update of website content does not apply any changes to the configuration of the web server, so why should the web server fail to read a site after it was updated? Because the site has a setting that interferes with the web server configuration.

Maybe you can ask Plesk support about this? They can check it directly on your server.

You should also place a phpinfo.php file into your document root directory of your website and open that file directly through the browser. Does this display the phpinfo() page or does it fail just as other scripts of the website do?

<?php phpinfo() >
 
I guess I could get it solved now. Your idea concerning a cache problem was right. I disabled opcache and apc-cache for the subdomain and now it works again.
Probably this didn't come out when I used the previous version of Plesk as I started to optimize metatags just know what seems to interfere with the (probably) apc-cache more then other things I optimized in my Drupal installation in the past. However, thanks for your help!
 
Back
Top