Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#61 [patch] Retry on CURLE_COULDNT_CONNECT

open
2014-08-21
2012-02-16
Andrew Zhezherun
No

When using curl, I sometimes get random "couldn't connect to host errors". I am not sure what is causing them, but the server looks to be operational, and running the same command after a few seconds usually works. I tried to use the --retry option, however it turned out that it treats CURLE_COULDNT_CONNECT as a fatal error and does not try again if it occurs. Could this error code be included please when curl determines whether to retry? I have attached a patch that should address this issue.

Discussion

  • Patch to enable retry on CURLE_COULDNT_CONNECT

     
    Attachments
    • summary: Retry on CURLE_COULDNT_CONNECT --> [patch] Retry on CURLE_COULDNT_CONNECT
     
  • The point with --retry is to make it retry operations for transitional errors. Those are errors that are likely to change over time. Most of the transitional ones are such due to what the application layer protocol itself says they are.

    I don't think a failure to do a TCP connect is a typical transitional error. I also don't think that adding non-transitional errors to the list of errors to do retry for is a good idea, as if we can add such we pretty much can ditch the check and retry for all possible errors.

    For your particular problem here and now, you can quite easily write a shell script for your case that re-sends the same command if this particular error is returned.

     
  • Thanks for the comment! I am not sure what the definition of a transitional error exactly is, but in my case the error does change over time as it disappers after retrying. If curl's treatment of error codes is strict, then maybe there could be a separate option e.g. --retry-on-all-errors that would achieve what I want. I agree that I can write a wrapper script instead, I just thought that it would be nicer to have this option directly in curl, in case I am not the only one having this problem.

     
  • FWIW, I consider a TCP connect error "transitional" (or at least temporary) if we're waiting for the server to come up. I've seen multiple application startup scripts try and use "curl --retry" to wait for the http server to start, but instead have to be switched to use "wget --retry-connrefused" instead.

    Perhaps you could use another flag like wget does, as though you assert that just doing a loop for "tcp connect" in the shell script calling curl is an option, by the time you add sleeping/limited retries/etc., it really is preferable for me as a user to just let curl use its existing sleep/retry functionality instead of me reimplementing it for the 1 error (tcp connect) that it doesn't loop on.