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

From: Date: Mon, 02 Sep 2019 21:17:57 +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-222534@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: Seeing as I've never seen this happen on my previous host, I suspect it's a conflict with some local setup, not a bug in curl itself - but it'd be nice if there was a way to find out what could possibly cause it to behave like that. Previous Comments: ------------------------------------------------------------------------ [2019-09-02 20:54:23] sinus at sinpi dot net 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>". ------------------------------------------------------------------------ [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..? ------------------------------------------------------------------------ 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 (#222534) next »