libcurl, sorry too early in the morning not reading properly, lol
Stripe Network Communication Error
No problem, I hope this is what was causing you problems so that it can be resolved. Consider the entire phrase that they used:
libcurl which was done automatically by the YUM package manager
1 Like
Nice catch Linda. This is one of the reasons I use IaaS cloud (AWS, Azure, etc) and not shared / managed hosts…they upgrade on their schedule not ours and they make changes without notifying people. Because they don’t manage the application tier they don’t test for application level consequences.
Thanks for sharing 
Sadly moving back to PHP 7.3 as well as downgrading curl as well as libcurl did not solve the problem for me.
Any other suggestion would be highly appreciated
All yum updates in the past week have now been rolled back but still no change :’(
Your original comment was “My Stripe has been working fine until 4 days ago.”
The rule of computing is “if tech works an then stops working…someone has touched something…find out who & what then reverse it.”
So you need to talk to your hosting company and ask what they did 4 days ago assuming you did not make any changes 4 days ago (upgraded plugin / WordPress).
Actually…your error log above shows it is a curl error. Talk to your hosting company.
I can see that the server did two automatic yum updates on the days when things stopped working. These are the updates that I rolled back without any luck.
I am seeing other folks reporting the same problem starting around the same time regarding other plugins so it isn’t a s2member only issue, but one that will affect others as well.
Did you restart your web server (apache / nginx) after the curl rollback? If you’re on shared hosting then that is problematic because you would share a web server. Given that you were able to rollback the curl update I will assume you have your own web server.
yes I did restart after each change before retesting. I have my own VPN via GoDaddy with only my own personal sites on it so any changes or updates I do don’t affect anybody else.
thank you for your help so far I do appreciate it. I have so far spent three days trying to sort this out so any help goes a long way to getting the $$$ coming back in at this crazy time.
It is still a curl issue. Talk to your hosting company again.
You are not alone. Do a search in Google for the following phrase from your logfile:
curl Network error [errno 2]: easy handle already used in multi handle
These guys all had the same problem starting at the same time as you. See https://wordpress.org/support/topic/curl-error-2-easy-handle-already-used-in-multi-handle/
See the following comment from that post…
This issue is currently resolved for us. The first thing that seemed to work was turning the cURL keep-alive off, so the handle was never reused.
I turned the keep-alive back on, and the site continues to work. This may have coincided with our web host rolling back the cPanel cURL version. Turns out the cURL error began after a cPanel update where cURL went from version 7.69.1 to 7.79.1.
Though our installed cURL package is version 7.19.7, PHP uses the cPanel version which is now back to 7.69.1.
I did find that topic today and did try to turn keep alive off then do a test purchase, then back on again with another test purchase. I did this via .htaccess as well as via httpd.conf, both with no success.
I have the same cURL package as them as well as PHP using 7.69.1
I try giving GoDaddy a call in the morning to see if they have a solution
Ok, checking in again. It is definitely the “libcurl which was done automatically by the YUM package manage” I hve a managed dedicated server with fastcomet. After I sent this info a couple days ago, the server host fixed it and I was able to sign up/pay/connect to stripe with no problems on a test account. Then, today, a new person tried to sign up and once again encountered the same problem as before. So, I copied off the info that you provided @onepresstech:
Start copy:
curl Network error [errno 2]: easy handle already used in multi handle
These guys all had the same problem starting at the same time as you. See https://wordpress.org/support/topic/curl-error-2-easy-handle-already-used-in-multi-handle/
See the following comment from that post…
This issue is currently resolved for us. The first thing that seemed to work was turning the cURL keep-alive off, so the handle was never reused.
I turned the keep-alive back on, and the site continues to work. This may have coincided with our web host rolling back the cPanel cURL version. Turns out the cURL error began after a cPanel update where cURL went from version 7.69.1 to 7.79.1.
End Copy
And then my server host just contacted me back with this info:
Start Copy:
“So what I have done is downgraded the libcurl version once more and have just excluded the libcurl from the automated updates in the YUM package manager so the issue should have subsided right now. Please test the matter and if still encounter such an issue,”
End Copy
I contacted stripe also and they do not show this issue showing up in their logs, so I can’t confirm with them.
I just received notifications from the client and stripe that she successfully signed up. So, I think that this may be the total solution for now. Hope that helps.
1 Like
I did that process again Linda, but still no luck on my side. Thanks anyway
YES!
I fixed the problem.
In this file:
s2memberpro/src/includes/classes/gateways/stripe/stripe-sdk/lib/HttpClient/CurlClient.php
go to line 44 which looks like this:
protected $enablePersistentConnections = true;
and change it to:
protected $enablePersistentConnections = false;
It is the persistent connection that is breaking the process at Stripe
Glad you got it working.
For those reading this, please note that while setting $enablePersistentConnections = false; may eliminate the symptom it is still not clear what the problem is.
For those who are experiencing this problem please go to the Stripe PHP SDK Issues area. This is still considered an open issue that Stripe are trying to solve with the help of people like you.
See https://github.com/stripe/stripe-php/issues/918
NOTE: The side-effect of setting $enablePersistentConnections = false; is that the communications will no longer support HTTP Keep-Alive which will slow down communications between your server and the Stripe Gateway server and may trigger a timeout on busy eCommerce platforms. If your eCommerce traffic is low (less than 1-transaciton-per-minute), however, the lack of HTTP Keep-Alive support should not be an issue.
NOTE2: Next time you update S2Member Pro plugin remember to re-patch. I would not be promoting to @clavaque that this be disabled in the s2memberPro copy of the Stripe SDK. Once there is a proper fix by Stripe identified in https://github.com/stripe/stripe-php/issues/918 then we can look to patching the s2member plugin’s copy of the Stripe PHP SDK.
1 Like
Was there any more info on this? We are still having the problem, intermittently. in the logs, it says Curl Error 28, which is a bit different. Also, we are using Auth.net, not Stripe.net. Not sure if that’s related or not.
$enablePersistentConnections = false; we cannot find that line in Auth.net files, perhaps we’ve missed it… But we can’t find it.
Also, we’ve tried rolling back as far as as possible to 7.0php, CURL-7.19.7 and there were no changes on YUM the day it started, June 5th.
We’d like to know how to replicate it, how to cause CURL to overload? timeout? i think it’s at 10000 now… so… plenty of time.
We need to plugins… we have the ability to edit them… but… just don’t know what’s causing it to randomly occur… Server load?? traffic? ( we don’t have that much)…
Please help… it’s been almost a week.
CURL Error 28 timeout issues are a server issue not an s2member issue. You need to talk to your hosting company and talk to Authorize.net depending on whether the CURL error was on a message sent to Authorize.net from your server or the other way around.
This thread was about a different CURL issue that was configuration settings related.
Try to figure out what changed on June 5th if you can.