Stuart Henderson <stu@spacehopper.org> wrote:

> On 2026/04/09 22:09, Klemens Nanni wrote:
> > sthen:
> > > curl's --connect-timeout default is 5 minutes. this includes DNS (which
> > > can be quite long if you have a few NS listed) and TLS (in particular,
> > > the handshake can stall if you have MTU issues). I believe ftp(1) just
> > > uses this on the connect call which would not be equivalent.
> > 
> > 
> > 5m and 15s seem a little too long and short for ftp, given it has just
> 
> 15s for a TCP connect() timeout doesn't seem too bad actually.
> 
> > one knob to time out.
> 
> It's not just that it just has one knob; there's _no_ specific timeout
> for dns lookups, so they can take much longer. TCP connect timeout
> happens after that.
> 
> And the MTU issue for TLS is a real problem with some broken networks
> and again a connect timeout doesn't help you there, it can still be
> hanging without progress at that point (after the connect timeout is
> done).
> 
> I don't object to sprinkling some -w, but it seems like it only deals
> with about a quarter of the problem.

True, true.  No matter what words get used to document it, there will
always be the assumption that the timeout argument is the sum of all the
delay factors.  It should not take longer than that.  Except you are
right, it does.

So maybe all this code should be refactored to use a SIGALRM, which
taps a global volatile sig_atomic_t and interrupts operations, and
that variable can get inpected in various places to cause termination.

It becomes easier to document how it works, and the command will never
run longer, and the default timeout and optional timeouts can be set
with confidence.