Syncing data and performing multiple Updates via MainWP

stevew52 · January 13, 2022, 1:30am

Hello,
I have two annoying performance/site to site conversation issues that I’d like input on, and hopefully the key to solving them.

First of all, just to let you know, I manage my own server and can make any changes I need to. All my sites (including the MainWP Dashboard) are on this web server and all have the same IP address. I currently have 25 sites connected to MainWP.

When I initiate Sync Dashboard with Child Sites, often but not always one or two will come back with the yellow exclamation point (!). I can then retry just the “failed” sites, and they will sync just fine. However, I don’t know why they return this “warning” and “fail” to begin with. I have played with the settings a lot, and nothing I’ve tried seems to solve this issue. This issue seems to have come up sometime around the upgrade to PHP8. I didn’t have this happening before, and it’s not a HUGE problem, but annoying that I don’t know the reason. Any thoughts?
When I try updating multiple sites via the MainWP interface, 2 or 3 will work then the next one or two will not complete, and hold up all others in the queue, and I have to close the pop-up/progress box, and there will be one or two of my sites left in maintenance mode for a couple of minutes, until they can be accessed once again. When I get back into them, they are back to still needing an update. So, I can’t use MainWP to update multiple sites anymore. It used to work perfectly fine with the same number of sites. And if I go to the site’s wp-admin, and perform any kind of an update, they almost never fail and they never get stuck in maintenance mode for any period of time.

So, I feel like communication between the MainWP dashboard and the connected sites is getting halted or broken in both of these issues, and I’m not sure where to go from here.

I will paste my server status report here for you to look at, but it definitely could be a security measure applied by a “threat team” technician, since I have a Secure Server Plus package added to my web server plan, but again, I’m at a loss as to how to track down where these issues are coming from.

stevew52 · January 13, 2022, 1:41am

I’ve removed some sensitive info here. I believe this is the important stuff.

MainWP Dashboard Version 4.1.11 4.1.11 Pass
MainWP Upload Directory Writable Writable Pass
MainWP Extensions
WPvivid Backup MainWP 0.9.22
WordPress
WordPress Version >=3.6 5.8.3 Pass
WordPress Memory Limit >=64M 256M Pass
MultiSite Disabled =true true Pass
FileSystem Method = direct direct Pass

PHP Version >=7.0 8.0.14 Pass
PHP Safe Mode Disabled =true true Pass
PHP Max Execution Time >=30 seconds 300 Pass
PHP Max Input Time >=30 seconds 300 Pass
PHP Memory Limit >=128M 256M Pass
PCRE Backtracking Limit >=10000 1000000 Pass
PHP Upload Max Filesize >=2M 64M Pass
PHP Post Max Size >=2M 128M Pass
SSL Extension Enabled =true true Pass
SSL Warnings = empty Pass
cURL Extension Enabled =true true Pass
cURL Timeout >=300 seconds 300 Pass
cURL Version >=7.29.0 7.81.0 Pass
cURL SSL Version >=OpenSSL/1.1.0 OpenSSL/1.1.1m Pass
PHP Allow URL fopen YES
PHP Exif Support YES ( V8.0.)
PHP IPTC Support YES
PHP XML Support YES
PHP Disabled Functions exec, passthru, shell_exec, system,
PHP Loaded Extensions Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, cgi-fcgi, ctype, curl, date, dom, enchant, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imagick, intl, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcntl, pcre, pdo_mysql, pdo_sqlite, posix, pspell, session, soap, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib
MySQL
MySQL Version >=5.0 5.7.36 Pass
MySQL Mode NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
MySQL Client Encoding utf8mb4
Server Info

Server Software Apache
Operating System Linux
Architecture 64 bit
Server IP 67.227.190.42
Server Protocol HTTP/1.1

HTTPS ON
Server self connect Not expected HTTP response body:
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Server Port 443
Gateway Interface CGI/1.1
Memory Usage 36.84 MB

page=SettingsAdvanced
Request Time 1642034911
Accept Content text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Charset Content N/A

Remote Host N/A
Remote Port 57568
MainWP Settings
Number Of Child Sites 25
Use WP-Cron Yes
Optimize for Shared Hosting or Big NetworksYes
Automatic Daily Update Disabled
Abandoned Plugins/Themes Tolerance 365
Maximum number of posts to return
Maximum number of pages to return

Maximum simultaneous requests 4
Minimum delay between requests 200
Maximum simultaneous requests per ip1
Minimum delay between requests to the same ip1100
Maximum simultaneous sync requests 6
Maximum simultaneous install and update requests2

stevew52 · January 13, 2022, 1:54am

One other thing I think I should mention, although I don’t think this is the problem -

Just one of my sites is still on PHP 7.4.27 and we will be redesigning this site very soon to bring all sites up to PHP8, finally. This particular site does not function on PHP8 because of how some part(s) of the custom code was written (by another web designer/coder). This site is not one that tends to fail or display the issues I’ve explained here, but maybe it has something to do with it, so I thought I’d let you know, just in case. Thanks

bogdan · January 13, 2022, 3:17pm

Hi @stevew52,

Just to be 100% sure, are you able to temporarily roll back PHP version to 7.4 on your dashboard site and see if that helps?

stevew52 · January 13, 2022, 6:17pm

Sure. I too was thinking of trying this, but hadn’t yet for some reason. It didn’t dawn on me immediately, because it wasn’t like when I upgraded to PHP8, things stopped working or I was suddenly getting all kinds of errors. It was later when I began to notice more things and certain things failing more often. When I thought back to when I might have noticed it getting worse, it may have begun shortly after I updated everything except that one site.

So, I just set my MainWP Dashboard site back to 7.4 and I tried updating 6 sites at once, and it worked fine. This is progress! So, let me play with it a little more and I will let you know if things seem to be resolved completely or not. Thanks for looking at this with me. I really appreciate the quality of support you provide to your users!

bogdan · January 13, 2022, 7:14pm

Hi @stevew52,

thanks for the update.
However, since we released PHP 8 support recently, there could be some other plugin causing the problem.
Have you tried to disable all plugins except for the MainWP Dashboard on the site and see if everything works normally on PHP 8?

stevew52 · January 13, 2022, 7:44pm

Hi Bogdan,

I will try that. And as I had mentioned, Soon all sites will be running on PHP8, so I will be finally able to leave 7.4 in the dust, and have no sites using 7.4. So, at that time, I will see if there are any issues with everythnign on PHP8. Again, thanks for looking at this with me, and I’ll be in touch if I have any further issues.

kwcjr · January 13, 2022, 8:34pm

@stevew52 Yes do be sure to test as much as you can running PHP 8 and record your findings. We are striving to get things in order & fixed as edge cases arise with that version.

Thank you for your understanding & testing.

stevew52 · January 14, 2022, 1:00am

sure thing! thanks Keith.

stevew52 · January 14, 2022, 9:52pm

So, referring back to issue 1 (syncing failures), here’s an example of what I can show you from an attempt last night.

MainWP Dashboard running PHP8
I have 25 sites
initiated a sync, 23 were able to sync and two gave me the yellow exclamation point
(This is typical behavior, however 20-25% of the time, they all work with no errors.)

Here are the errors I can see in MainWP from this instance -

14-Jan-2022 18:03:33 UTC	PHP Fatal error: Uncaught TypeError: flock(): supplied resource is not a valid stream resource in /home/xxxxx/xxxxx.xxx-xxx.com/wp-content/plugins/mainwp/class/class-mainwp-connect.php:1174
14-Jan-2022 18:03:33 UTC	PHP Fatal error: Uncaught TypeError: flock(): supplied resource is not a valid stream resource in /home/xxxxx/xxx.xxx-xxx.com/wp-content/plugins/mainwp/class/class-mainwp-connect.php:1174

And, Here is a snippet from around the 1174 line of code -

if ( function_exists( 'sem_acquire' ) ) {
		return sem_acquire( $identifier );
	} else {
		for ( $i = 0; $i < 3; $i ++ ) {
**Line 1174		if ( @flock( $identifier, LOCK_EX ) ) {
				return $identifier;
			} else {
				sleep( 1 );
			}
		}

		return false;
	}

	return false;

Do you have any suggestions on how I can get these errors to stop or be much less frequent?
I have tried deactivating plugins, and it seems not to change anything with this issue.
When I roll back to PHP7.4 the MainWP Dashboard site, a sync almost never gives me an error.

I’m currently waiting for more updates to drop to further testing on issue 2.

stevew52 · January 15, 2022, 12:02am

I posted again with results from an error being generated when not all my sites sync. I guess the post is currently flagged to be looked at by someone because the examples I listed triggered Akismet . Hoping to see it added to the thread soon. Thanks!

kwcjr · January 15, 2022, 12:27am

@stevew52 I pushed it though for you. ~ I will try to keep an eye out if that happens again over the weekend. Thanks for your patience.

kwcjr · January 15, 2022, 12:44am

@stevew52 This may seam strange but have you reached out to your Hosting Company to see if they are blocking your Dashboards IP? I do know that the PHP Method flock() is sometimes used in “Hacking” tools to obfuscate malicious code. In our case we are using it for security. That code snippet checks to see if the PHP Method ‘sem_acquire’ exists within the environment and if it doesn’t it tries to use flock() which is “sometimes failing” on your server.

I would go to your Hosting Company with this information and see if they can shed light on as to why that method would fail sporadically if it’s not a time out issue…To me it seams like it could be “blocked”?

flock() is supported by PHP8 so this should work.

I am currently running PHP8 on my setup & I am not seeing these issues that you are describing. I will continue to monitor my setup to see if this also happens with mine.

stevew52 · January 15, 2022, 1:26am

I thought of that too initially, and it does feel like it could be a timeout issue, which would explain why it occurs with various sites, one or two at a time at random. However, this does not happen when I rollback to PHP7.4 on the MainWP Dashboard site. Only when I’m running it on PHP8.

And as far as it possibly being blocked by a tight security setting, I referenced that as well in the original post, I think, but then I question, "why wouldn’t it happen more often and also why only after updating to PHP8?

I do really want to know, and I want to understand how and where the fix is applied, for my own knowledge! Always learning. I have a lot of experience with servers and networks, but a setting up a web server and understanding PHP is something I decided to get into just a little over a year ago. So, I’m eager to soak up anything relevant pertaining to all this, and I do really like MainWP, having tried other options.

stevew52 · January 15, 2022, 1:30am

Cool. Thanks! I appreciate it. I’ll continue looking into all the stuff you mentioned, as well.

kwcjr · January 16, 2022, 10:07pm

@stevew52 Yeah it does sound like a “timeout” if the hosting company isn’t blocking it when you test downgrading to 7.4.
I am not not able to replicate your specific issue yet, but we do have other issues that need to be addressed. MainWP 4.1.11 should be PHP8 compatible aside from some edge case issues. I would run in 7.4 for the time being on your Production environment until we can figure out what’s going on with your setup.

Would you mind opening a private Help Desk ticket so we can collect some additional information & investigate further?

system · February 15, 2022, 10:07pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.