Bug #78485 [Com]: Random "couldn't resolve host" failures in curl_multi

From: Date: Mon, 02 Sep 2019 20:54:23 +0000
Subject: Bug #78485 [Com]: Random "couldn't resolve host" failures in curl_multi
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-222532@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78485&edit=1 ID: 78485 Comment by: sinus at sinpi dot net Reported by: sinus at sinpi dot net Summary: Random "couldn't resolve host" failures in curl_multi Status: Open Type: Bug Package: HTTP related Operating System: CloudLinux PHP Version: 7.2.22 Block user comment: N Private report: N New Comment: You might have to reload it a few times, as I said, it's pretty random. Reproductions of the bug are seen as "Msg: 6 for handle <x>". Previous Comments: ------------------------------------------------------------------------ [2019-09-02 20:51:30] sinus at sinpi dot net The issue can be seen at http://djab.eu/isuvu/bug.php with source viewable at http://djab.eu/isuvu/bug.php.txt . ------------------------------------------------------------------------ [2019-09-02 20:35:04] nikic@php.net Is there any publicly accessible host for which this might be reproduced? ------------------------------------------------------------------------ [2019-09-02 20:33:25] sinus at sinpi dot net I finally managed to make a workaround, the hard way: by stashing the failed handles and starting a whole new curl_multi_init session with just the failures. The original problem remains, though: why would n+1 handles immediately fail to resolve. ------------------------------------------------------------------------ [2019-09-02 19:39:20] sinus at sinpi dot net Trying another workaround, I built another retry mechanism, storing the failed downloads for later and only re-queuing them once the "good" downloads complete (getting a result==0 in curl_multi_info_read). However, it would seem that curl_multi does not, in fact, like having its list modified when it's running: my newly created curl_init handles, added anew, simply got ignored: curl_multi_exec's $still_running return silently dropped by one on the next round, as if it merely removed the new handle from its list. So another question arises - CAN curl_multi actually handle additions or removals of its child handles while in a curl_multi_exec session..? ------------------------------------------------------------------------ [2019-09-02 17:55:02] sinus at sinpi dot net To try and work around the issue, I wrote a retry mechanism - if a CURLE_COULDNT_RESOLVE_HOST message is detected, I curl_multi_remove_handle the handle, curl_close it, make a new curl_init and curl_multi_add_handle again, and return to calling curl_multi_exec. The docs don't state whether adding or removing handles during a multi session is permitted, so why not give it a try. The result, however, was exactly the same. All of the newly re-added child handles immediately got CURLE_COULDNT_RESOLVE_HOST results. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=78485 -- Edit this bug report at https://bugs.php.net/bug.php?id=78485&edit=1

« previous php.bugs (#222532) next »