• 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

Getting Error: Request to backend API failed with error: Request failed with status code 500

daedparrotsoftware

New Pleskian
Have latest Plesk Obsidian running Centos 7.x on a DEDICATED (our) server (Dual Xeons, 32 cores, 128G RAM, PHP 7.4.x)

Have several dozen WP installations. The sites are ALL working fine. No errors nothing of note in system logs
BUT
Periodically/sporadically, for no apparent reason, when I try to clone one WP installation to
a new subdomain (we do this all the time)

Doing the SAME clone attempt, I get one of 2 errors:

Request to backend API failed with error: Request failed with status code 500
or
Request to backend API failed with error: Request failed with status code 524

Sometimes 1, sometimes the other. There is NO other information, such as what API call, provided.

Anybody seen this? Google search turns up NADA

Sid b>
 
One Other thing - I get the error a LOT less frequently if I use the "clone" from the Toolkit dashboard for the site, instead of the "clone" button on the "Websites & Domains" part of the Plesk panel, EVEN THOUGH it is supposed to do the same thing! The websites&domains actually runs the same command as the WordPress Toolkit dashboard. That makes no sens :)

Sid
 
The 524 error indicates an FCGI timeout, meaning that the process was not completed before the server-side configured PHP interface timeout is reached. You can try at least these things to fix it:
a) Maybe you are using PHP via FastCGI instead of PHP via FPM in your PHP settings. Switch to PHP via FPM. It still uses the CGI interface, but in general it creates less load and processes things faster. So that might already solve the issue.
b) Upgrade the FastCGI timeout values in /etc/httpd/conf.d/fcgid.conf. Example:
FcgidIdleTimeout 60
FcgidProcessLifeTime 60
FcgidMaxProcesses 800
FcgidMaxProcessesPerClass 30
FcgidIOTimeout 60
Personally, I believe that such high values are not right, especially the timeouts serve a purpose to prevent run-away processes to use up system resources for no reason. But depending on the overall load and cpu resources of your system, you might need just longer timeouts so that processes can finish correctly without running into the timeout situation.
 
Hello, daedparrotsoftware,
I'm trying to reproduce your problem and I need some details.
"Websites & Domains" has 2 popular view options: Dynamic List and Active list. Could you clarify, please, what view you usually use when you click on the "Clone" button?
 

Attachments

  • Active list.png
    Active list.png
    150.8 KB · Views: 19
  • Dynamic list.png
    Dynamic list.png
    96 KB · Views: 15
The 524 error indicates an FCGI timeout, meaning that the process was not completed before the server-side configured PHP interface timeout is reached. You can try at least these things to fix it:
a) Maybe you are using PHP via FastCGI instead of PHP via FPM in your PHP settings. Switch to PHP via FPM. It still uses the CGI interface, but in general it creates less load and processes things faster. So that might already solve the issue.
b) Upgrade the FastCGI timeout values in /etc/httpd/conf.d/fcgid.conf. Example:
FcgidIdleTimeout 60
FcgidProcessLifeTime 60
FcgidMaxProcesses 800
FcgidMaxProcessesPerClass 30
FcgidIOTimeout 60
Personally, I believe that such high values are not right, especially the timeouts serve a purpose to prevent run-away processes to use up system resources for no reason. But depending on the overall load and cpu resources of your system, you might need just longer timeouts so that processes can finish correctly without running into the timeout situation.

ALL sites on the server use FPM so it's not a FastCGI issue. And Apache is running in Event mode. The sites themselves are having NO issues of any kind. This is only happening when cloning.

Thanks for your help!

Sid
 
Hello, daedparrotsoftware,
I'm trying to reproduce your problem and I need some details.
"Websites & Domains" has 2 popular view options: Dynamic List and Active list. Could you clarify, please, what view you usually use when you click on the "Clone" button?
We use Active list when in the "Websites & Domains" section of Plesk panel.
The WordPress Tools admin interface looks more like the Dynamic.
It is when using the Active list page that we get the error most often - usually I can go to
"WordPress Tools" and retry clone there, and it works.

Thanks for your help. Attached to images to clarify.

Sid
 

Attachments

  • plesk-clone1.jpg
    plesk-clone1.jpg
    145.1 KB · Views: 9
  • plesk-clone-2.jpg
    plesk-clone-2.jpg
    159.6 KB · Views: 8
Have you tried (b) or is it an assumption that longer timeouts won't fix it?
No we did not extend values for fastcgi beyond normal. Not sure if tech made any adjustments to FPM but I don't believe so.
With only 2 dozen small WP sites on a server like this - 128G of RAM, all drives are SSD, etc. - just shouldn't be seeing timeouts.

sid
 
I've been digging into this problem, and here's what I found:

WordPress Toolkit doesn't use 524 status code at all.

It looks like 524 status code is about CloudFlare.

Error 524 indicates that Cloudflare successfully connected to the origin web server, but the origin did not provide an HTTP response before the default 100 second connection timed out. This can happen if the origin server is simply taking too long because it has too much work to do - e.g. a large data query, or because the server is struggling for resources and cannot return any data in time.

CloudFlare support

You can search some additional information in logs of sw-cp-server, e.g. whose the timeout fails (sw-engine most likely).
Article in Plesk Support about logs

And it may be useful to look into the Plesk log.
plesk log panel.log
Perhaps there will be more information if these are errors on the part of the WordPress Toolkit
 
Yes we figured that out. Only got the cloudflare error twice. Fixed that by clearing the edge cache.

the 500 errors started 2 days later. Got those errors 58 times. Over 2 days. They have nothing to do with
Cloudflare. WE got the error even after going to development mode and completely bypassing Cloudflare.

Thanks

sid
 
Unfortunately, I can't reproduce your problem. Anyway, we are planning several internal improvements on Cloning in the next release, so it is very likely that the problem can be fixed in the next version of the WordPress Toolkit.

If the problem continues to bother you, could you please create a ticket in Plesk support. Our engineers will do their best to help you :)
 
Thanks for the help

Our plesk came thru the hosting company with the server. We don't have a direct license, (it shows in their system as a 'reseller' account) which is only an issue when making support requests to Plesk. They won't accept them! Which is irritating but only problematic in this situation.

When it works Clone and Copy Data functions are VERY useful. We use them a LOT. Please don't mess them up! LOL
The only thing Clone doesn't do (besides this issue) is copy the Apache & NGnix settings from the source to the target. We have to do those manually.

I look forward to the updates. Thanks :)

Sid
 
We're going to keep the clone and the sync working well. :)

And thank you for your feedback about copying the Apache & Nginx settings, I will pass this to our Product manager.
 
Back
Top