In one of our systemd units that depends on network.target, we had an odd scenario where the network bounced a bit on startup. This happened to have a down period when right when a curl command tried to fetch over http. The command failed with Immediate connect fail for 169.254.169.254: Network is unreachable and did NOT retry despite having retry flags set (--max-time 10 --retry 5 --retry-delay 10).

As far as I can tell this is because the retry mechanics at https://github.com/curl/curl/blob/curl-7_54_0/src/tool_operate.c#L1573 do not check for CURLE_COULDNT_CONNECT(7), even though the network being unreachable is often transient or temporary.

This is very easily reproducible by being on a laptop and disabling wireless (assuming no wired connection) and attempting a curl command with retry. Then enabling the wireless and trying again.

I did this

Executed curl with retry flags set but with no network active. For example, turn off wireless on your laptop and do

$ /usr/local/Cellar/curl/7.54.0/bin/curl -v 8.8.8.8 --max-time 60 --retry 5 --retry-delay 10 --retry-max-time 30 --retry-connrefused
* Rebuilt URL to: 8.8.8.8/
*   Trying 8.8.8.8...
* TCP_NODELAY set
* Immediate connect fail for 8.8.8.8: Network is unreachable
* Closing connection 0
curl: (7) Couldn't connect to server

I expected the following

Retry on errors

curl/libcurl version

curl 7.54.0 (x86_64-cros-linux-gnu) libcurl/7.54.0 OpenSSL/1.0.2k zlib/1.2.11 c-ares/1.12.0
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM SSL libz TLS-SRP UnixSockets HTTPS-proxy

operating system

Linux 4.9 (CoreOS)