PHP Fatal error: Uncaught GuzzleHttp\Exception\RequestException: cURL error 2: easy handle already used in multi handle

[EsSa55]

Guzzle: 6.2.3
PHP: 7.3.16
Curl: 7.19.7

Description

Library used for Google Shopping API product feeds

Feeds worked successfully every 20 minutes for 2 years and first 5 hours of 17 April 2020

Then:

PHP Fatal error: Uncaught GuzzleHttp\Exception\RequestException: cURL error 2: easy handle already used in multi handle (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:162
Stack trace:
#0 ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(129): GuzzleHttp\Handler\CurlFactory::createRejection(Object(GuzzleHttp\Handler\EasyHandle), Array)
#1 ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(89): GuzzleHttp\Handler\CurlFactory::finishError(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#2 ../vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(43): GuzzleHttp\Handler\CurlFactory::finish(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#3 ../vendor/guzzlehttp/guzzle/src/Handl in ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 162

No change to server, site configuration or any associated php or library files.

Same error every time the script now runs.

I am not a programmer but can follow instructions!

Any leads or guidance will be appreciated as the feed developer is no longer available.

TIA

[EsSa55]

Updated curl to v7.69.1. Issue persists

[GrahamCampbell]

Updated curl to v7.69.1. Issue persists

What do you mean by this? The curl cli binary you might have on your machine is not related to lib-curl.

[EsSa55]

Sorry, by 'issue persists' I mean the error is the same.

There is a possible solution on stackoverflow but it applies to Stripe and I have no idea how to implement it in Guzzle

[GrahamCampbell]

I mean what did you mean by updated curl?

[EsSa55]

Upgraded the curl version

[GrahamCampbell]

What do you see when you run php -r 'echo curl_version()["version"];'.

[EsSa55]

7.69.1

And all is well again.

I have removed curl & libcurl from yum so that they do not update.

I guess that's not the ideal solution but the only one I am able to implement in order to get my scripts working.

Thanks

[ingberrio]

I get the same problem, GuzzleHttp\Exception\RequestException: cURL error 2:, this appear when on godaddy service active ssl with some browser not working (safari, firefox), I`ve the same configuration.

Before a long days my fix, Put StreamHandler instead of CurlHandler

[pavelgajdos]

It helped me to configure the client as follows:

$client = new Client([
    'handler' => new CurlHandler([
         'handle_factory' => new CurlFactory(0)
    ])
]);

However, I still think there is a bug somewhere. It stopped working on its own, nothing has changed neither in the app or on the server.

Edit

I was told that there may had been an automatic update as we use cPanel on that server. Unfortunately, I don't know more.

[capuderg]

Hi,

some of our users are also reporting this issue: https://wordpress.org/support/topic/curl-error-2-easy-handle-already-used-in-multi-handle/

In our WP plugin: WP Mail SMTP we are using "google/apiclient" lib and it requires guzzle.

I can't reproduce this issue on my shared hosting or locally.

There were no changes to the plugin code when this issue started appearing for our users.

@EsSa55 When you say "All is well again", does that mean that the error is no longer present for you? Did cURL update on your server when these errors started to appear? Did you downgrade to an older version of cURL in order to resolve this issue?

[EsSa55]

@capuderg That's right. The error is no longer present, having requested my server host to downgrade cURL + libcurl to the previous version.
cURL did update automatically on my server. Sorry, I don't actually know what the new version was.

curl -V
curl 7.69.1 (x86_64-redhat-linux-gnu) libcurl/7.69.1 OpenSSL/1.0.1e-fips zlib/1.2.3 c-ares/1.16.0 libssh2/1.8.2
Release-Date: 2020-03-11
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS GSS-API HTTPS-proxy IPv6 Kerberos Largefile libz Metalink NTLM NTLM_WB SPNEGO SSL UnixSockets

[ingberrio]

It helped me to configure the client as follows:

$client = new Client([
    'handler' => new CurlHandler([
         'handle_factory' => new CurlFactory(0)
    ])
]);

However, I still think there is a bug somewhere. It stopped working on its own, nothing has changed neither in the app or on the server.

Edit

I was told that there may had been an automatic update as we use cPanel on that server. Unfortunately, I don't know more.

Before a long days my fix, replace StreamHandler instead of CurlHandler

[EsSa55]

Posted by @matt on https://stackoverflow.com/questions/61285075/php-fatal-error-uncaught-guzzlehttp-exception-requestexception-curl-error-2-e?noredirect=1#comment108426410_61285075

Temporary fix:

Just in case anyone reading this is using Laravel. We suddenly started having the same problem a few days ago, tried installing different cURL versions and setting cURL options, nothing worked. I fixed it by changing the vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php file. Look for the line that says

if (count($this->handles) >= $this->maxHandles) {
curl_close($resource);
} else {
...
}
Comment this all out, and instead of the if/else just write

curl_close($resource);

In other words no matter what the handles count is you always close the cURL connection. This worked instantly for us!

I thought the cURL version downgrade was the 'fix', but it worked for just 2 days.

[pavelgajdos]

@EsSa55 I got inspired by this solution but instead of commenting out packaged lines of code I kind of forced the condition to be always true, therefore closing a resource every time. In my previous comment the number 0 is assigned to $this->maxHandles

[EsSa55]

@pavelgajdos As a non-programmer, I was able to follow the instruction re specific commenting out. However, I am lost as to where/how your solution is applied re 'configure the client'.

[pavelgajdos]

@EsSa55 In this case you are better off with commenting the lines out even though it is not as clean solution as mine or @ingberrio's :-)

Applying my solution heavily depends on your specific software and a guide, which would cover most possible situations in your code, would be too long and unnecessary for this issue.

Anyway, I hope we will know a cause of this bug or there will be a hotfix soon.

[GrahamCampbell]

curl -V

This does not tell you the version of libcurl PHP is using.

[sandervanhooft]

Can someone confirm this is an issue caused in this package?

I’m getting reports of this issue in one of my packages that requires guzzle, but cannot reproduce it.

[Gaffen]

This issue is also being encountered in Stripes' php client, with reference to guzzle:
stripe/stripe-php#918

[Gaffen]

I also believe this issue is being encountered with https://github.com/awesomemotive/WP-Mail-SMTP, for their gmail integration which also uses guzzle.

[gmponos]

From https://curl.haxx.se/libcurl/c/libcurl-errors.html

CURLE_FAILED_INIT (2)
Very early initialization code failed. This is likely to be an internal error or problem, or a resource problem where something fundamental couldn't get done at init time.

and from https://cdcvs.fnal.gov/redmine/projects/simons-dm/wiki/Curl_Error_Codes

If we ever get this from our probe script, it means we have a broken version of curl on the system we are using, which can't find its own parts. So the user installed their own curl and it didn't build correctly, etc. Have them check their PATH command search path etc. installed packages, etc.

Also from the original author:

Guzzle: 6.2.3
PHP Fatal error: Uncaught GuzzleHttp\Exception\RequestException: cURL error 2: easy handle already used in multi handle (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:162

So now let's head there: https://github.com/guzzle/guzzle/blob/6.2.3/src/Handler/CurlFactory.php#L162

🤔

[gmponos]

The only versions that I found this line match is 6.0.0 and 6.0.1 https://github.com/guzzle/guzzle/blob/6.0.1/src/Handler/CurlFactory.php#L162

Please check your setup and use an updated version.

[Gaffen]

@gmponos thanks for this. Guzzle is embedded as a dependency so I don't fully have access over this, however it does at least help isolate the problem.

I'll investigate the versions bundles with the two plugins that have it as a dependency and confirm. If it turns out the guzzle version is the issue and not guzzle itself it could mean this issue can be closed.

[capuderg]

In the WP Mail SMTP plugin the lowest Guzzle version that was used for a couple of releases now was '6.4.1'. Even when this issue started to occur for our users the plugin used that version...

Here are some updates from the users experiencing this issue: https://wordpress.org/support/topic/curl-error-2-easy-handle-already-used-in-multi-handle/page/3/

A lot of users reported they are hosting on GoDaddy. Is this maybe a GoDaddy specific issue?

[Gaffen]

I'm pretty sure it's not godaddy; I think it might be something to do with CentOS (I've seen other centOS users report similar things - do you know if your godaddy users are on CentOS systems @capuderg ?)

[gmponos]

Firstly I can't safely exclude that this couldn't be a guzzles issue.. but I would like to have a stack trace that I can trust.

Secondly (not a WP expert) but unless you are using wppackagist then AFAIK WP plugins include all their vendor in the install right? How does the autoloading behaves when two plugins include in their vendors Guzzle? Maybe another plugin is using outdated guzzle version and it's the reason we have this stack trace?

If this "could" be an issue then what is the composer version used to generate the autoloading files for each version of you WP plugin?

[capuderg]

@Gaffen I don't have any additional info on their systems, apart from the info on the forum post I pasted above. Sorry.

[capuderg]

@gmponos If two WP plugins use the same composer package then the plugin that calls the autoload first will "register" the package and the second plugin's package will be ignored...

I've asked a user to list all plugins that he uses and verified if there is some kind of conflict like this, but there was none.

[amitshahc]

I am facing the same issue. I can't downgrade the things on the server. when we deployed the project the socialite plugin was working perfectly. suddenly it started throwing above error in the logs. please provide the solution asap. i also don't prefer to change in vendor files.

[Sensetivity]

I also facing this problem.

PHP 5.6.40 (cli) (built: Jun 15 2020 20:46:06)
cURL 7.69.1
guzzlehttp/guzzle 6.5.5

Exception 'Google\Cloud\Core\Exception\ServiceException' with message 'cURL error 2: easy handle already used in multi handle (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)'

[amitshahc]

Posted by @matt on https://stackoverflow.com/questions/61285075/php-fatal-error-uncaught-guzzlehttp-exception-requestexception-curl-error-2-e?noredirect=1#comment108426410_61285075

Temporary fix:

Just in case anyone reading this is using Laravel. We suddenly started having the same problem a few days ago, tried installing different cURL versions and setting cURL options, nothing worked. I fixed it by changing the vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php file. Look for the line that says

if (count($this->handles) >= $this->maxHandles) {
curl_close($resource);
} else {
...
}
Comment this all out, and instead of the if/else just write

curl_close($resource);

In other words no matter what the handles count is you always close the cURL connection. This worked instantly for us!

I thought the cURL version downgrade was the 'fix', but it worked for just 2 days.

I had to use the temporary fix mentioned here. but I don't recommend this and the developer should come up with the solution asap.

[jamesozzie]

Downgrading the libcurl version resolved a similar issue for a Site Kit plugin user, as reported here.

[irondan]

I'm in the (unique?) position where I'm managing a handful of Drupal sites. This error prevents some of them from retrieving information about project updates (the core Update module in Drupal 8/9 uses Guzzle to retrieve this information). Here's what I'm seeing:

Test	Drupal Version	PHP Version	cURL Version	Fails With error 2
Site 1 Prod	8.9.3	7.3.21	7.71.1	No
Site 1 Stage	8.9.3	7.3.20	7.71.0	No
Site 2 Prod	8.9.2	7.2.33	7.71.1	No
Site 2 Stage	8.9.2	7.2.33	7.69.1	Yes
Site 3 Prod	8.9.3	7.3.14	7.29.0	No
Site 3 Stage	8.9.3	7.3.21	7.69.1	Yes
Site 4	9.0.3	7.4.8	7.29.0	No

Far from conclusive information to be sure, but it's looking like this issue might be version specific to cURL. I will try updating that specifically any come back with any results.

[Nyholm]

As @gmponos shows, it is likely a curl issue.

I’m closing this since nobody has shown a stack trace, a reproducible script or a reliable version of guzzle where this happens. Feel free to open a new issue if you can provide a short reproducible script.

[ItsMeStevieG]

I am still getting this while using 2 packages (Packagist libraries) from different developers that have guzzle as a dependency.

I am getting this using the Following:

CURL:
curl 7.74.0 (x86_64-apple-darwin20.2.0) libcurl/7.74.0 (SecureTransport) OpenSSL/1.1.1i zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.0 libssh2/1.9.0 nghttp2/1.42.0 librtmp/2.3 Release-Date: 2020-12-09 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz Metalink MultiSSL NTLM NTLM_WB SPNEGO SSL TLS-SRP UnixSockets zstd

Guzzle
guzzlehttp/guzzle (7.2.0)

Stack Trace:
Fatal error: Uncaught GuzzleHttp\Exception\RequestException: cURL error 2: (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://oauth.nitrado.net/oauth/v2/token in /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:211 Stack trace: #0 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(158): GuzzleHttp\Handler\CurlFactory::createRejection(Object(GuzzleHttp\Handler\EasyHandle), Array) #1 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(110): GuzzleHttp\Handler\CurlFactory::finishError(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory)) #2 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(47): GuzzleHttp\Handler\CurlFactory::finish(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory)) #3 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(28): GuzzleHttp\Handler\CurlHandler->__invoke(Object(GuzzleHttp\Psr7\Request), Array) #4 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(48): GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler\{closure}(Object(GuzzleHttp\Psr7\Request), Array) #5 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php(64): GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler\{closure}(Object(GuzzleHttp\Psr7\Request), Array) #6 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Middleware.php(31): GuzzleHttp\PrepareBodyMiddleware->__invoke(Object(GuzzleHttp\Psr7\Request), Array) #7 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php(71): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Request), Array) #8 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Middleware.php(63): GuzzleHttp\RedirectMiddleware->__invoke(Object(GuzzleHttp\Psr7\Request), Array) #9 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/HandlerStack.php(75): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Request), Array) #10 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Client.php(331): GuzzleHttp\HandlerStack->__invoke(Object(GuzzleHttp\Psr7\Request), Array) #11 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Client.php(107): GuzzleHttp\Client->transfer(Object(GuzzleHttp\Psr7\Request), Array) #12 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Client.php(123): GuzzleHttp\Client->sendAsync(Object(GuzzleHttp\Psr7\Request), Array) #13 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/league/oauth2-client/src/Provider/AbstractProvider.php(608): GuzzleHttp\Client->send(Object(GuzzleHttp\Psr7\Request)) #14 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/league/oauth2-client/src/Provider/AbstractProvider.php(621): League\OAuth2\Client\Provider\AbstractProvider->getResponse(Object(GuzzleHttp\Psr7\Request)) #15 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/league/oauth2-client/src/Provider/AbstractProvider.php(537): League\OAuth2\Client\Provider\AbstractProvider->getParsedResponse(Object(GuzzleHttp\Psr7\Request)) #16 /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/test.php(45): League\OAuth2\Client\Provider\AbstractProvider->getAccessToken(Object(League\OAuth2\Client\Grant\AuthorizationCode), Array) #17 {main} thrown in /Users/itsmestevieg/Sites/stevieg.online/oauth2-nitrado/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 211

Any help would be greatly appreciated.