--retry doesn't retry on connection timeout, if you don't pass --connect-timeout #4461
Comments
Previosly all connect() failures would return CURLE_COULDNT_CONNECT, no matter what errno said. This makes for example --retry work on these transfer failures. Fixes #4461
|
I think the logic has roughly been that the timeout error code is for when libcurl itself decides to give up due to timing constraints, while when a regular libc call fails it ends up in a plain PR #4462 changes this when connect() fails with a I'm just a tad bit worried this changes behavior for someone or that by returning a timeout error it might hint for users that they can extend the timeout value and get a better shot at it (which they can't since this is the TCP stack's timeout value which isn't easily accessible). |
|
Maybe the docs for |
|
Yeah, I'm rather convinced that this is the right fix. The little problem I've run into now is that there are three tests failing on the freebsd tests because the port it tries to connect to that it wants a connection refused from (it presumes port 60000 on 127.0.0.1 has nothing listening on it) instead causes an ETIMEDOUT so thus with this PR the return code is different and three tests fail! 😞 |
|
@bagder That sounds annoying! I've noticed before that on macOS, if you try to connect to a port that (a) has a socket bound to it, and (b) that socket has not called In my case I solved it by switching to port 2 as my "nothing should be there" port. I don't remember why 2 specifically. But using one of the low numbered ports that's been assigned to some protocol that hasn't been used for 50 years seems like a reliable way to get a port where nothing will be happening. |
|
That's a good idea, I'll try that. Thanks! |
I did this
240.0.0.1 is a reserved IP address, so connections to it should just time out. When using
--retry, I expected curl would report a timeout, and then retry the connection as requested. Instead, it reports a timeout, and doesn't retry the connection:If I add an explicit
--connect-timeout 10, then it works as expected:I suspect the problem is that curl's retry logic doesn't know that
connectresolving withETIMEDOUTshould be treated as aconnectthat timed out.I can sort of see the justification for this, even, if I squint. But this really confused me. In the real situation where I ran into this, I was getting transient errors in CI runs, and curl was reporting them as "connection timed out". So I checked the man page, it says
--retrycan be used to retry when connect times out, I added--retry, and then ... a few days later I got the error again. So then I thought there must be some kind of weird failure mode where the host was timing out all 6 connection attempts... I think ideally--retryshould just work in this case, but if not then at least the man page should be updated to warn about this.curl/libcurl version
operating system
Ubuntu 19.04
The text was updated successfully, but these errors were encountered: