Recent content by Bitpalast

I was able to reproduce the issue on a test server. That test server runs a default Alma 8, an (almost) default Plesk installation. I created a test domain, then a default Wordpress installation from the WP Toolkit, then backed up, then restored. The restore showed the same error that the...

MariaDB 10.11.13, but that should not influence anything. Maybe the issue is caused by a plugin or theme, e.g. that after a restore some "after_restore" function is triggered in Wordpress?

PHP 8.3.22, in the "additional PHP directives" section, add disable_functions = proc_open,proc_close

It ain't. We're seeing the download warning messages again on several servers nightly.

Username: TITLE WP Toolkit Restore function throws cosmetic errors when proc_open/proc_close are disabled in PHP PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE 18.0.70 #2 Alma PROBLEM DESCRIPTION When proc_open/proc_close PHP functions are disabled, the WP Toolkit "restore"...

Yep, let's check that first. It's likely a load issue as you already figured out. But it might not be the dumps. The dump process could drive CPU usage up by about one single core. It could be a a disk I/O issue that slows the system down. But it could also be data compression, which has a...

c) Remove backup schedule dataset from table "psa.BackupsScheduled"

A web server 500 error that is caused by a database dump is quite unlikely. What is the exact error message that is logged along with the 500 error code? Also, MySQL dumps should not impact regular database operations at all, because they are only read operations. Is it really a 500 error? Or...

@zvangi That's a different issue. Why not open your own thread for it? Also, the reason of the failure is already mentioned in the error message.

During the past few weeks, the issue only occured for a file ai-bolt.*, but not for the other Imunify files. However, the files you show in your list are the ones that have shown up here frequently before. Let's wait a bit longer. Maybe there are simply no updates at this time.

It doesn't matter. The issue is probably not caused by Plesk.

I think that on one server we might have caught a real hardware error with the PCIe interface on the RAID controller. But: We still saw this on two other machines lately. On one of them it might have been caused by too many processes, but we'll still need to see what will happen on that machine...

I think the problem is caused by missing OCSP server validation as described here: Issue - Potential issue with OCSP stapling

Not really. One problem is that when the servers are unresponsive yet the webserver for some reason might still want to address them, on systems with many websites an Nginx reload or restart will hang and eventually run into a timeout. In other words: The web server might not restart. This was a...

Thank you for the link! Very interesting. So it seems we've been very lucky that the web servers did not start hanging due to an impossible OCSP verification process as the verification servers went offline? Plesk should consider to update the extension and to remove the OCSP option from it.