24.02.2026 09:35, Klemens Nanni пишет:
> 23.02.2026 00:44, Kirill A. Korinsky пишет:
>> On Sat, 21 Feb 2026 18:30:14 +0100,
>> Klemens Nanni <kn@openbsd.org> wrote:
>>>
>>> 21.02.2026 15:00, Antoine Jacoutot пишет:
>>>> On Sat, Feb 21, 2026 at 08:48:58AM +0100, Matthieu Herrb wrote:
>>>>> Hi,
>>>>>
>>>>> I'm using syspatch -c in the monitoring system for a number of OpenBSD
>>>>> machines at work.
>>>>> From time to time the host listed in /etc/installurl becomes
>>>>> unavailable for hours. (I've seen that both with a dedicated mirror or
>>>>> with the cdn) causing monitoring errors because the agent (check_mk)
>>>>> is stuck.
>>>>>
>>>>> Adding a timeout option to the ftp(1) command run by syspatch -c is
>>>>> enough for me to not have the OpenBSD machines appear unresponsiv in
>>>>> the monitoring system.
>>>>>
>>>>> Would something like this make sense ?
>>>>
>>>> I think it does.
>>>> But why not add it to some of the other ftp(1) calls?
>>>
>>> ... and sysupgrade(8) and bsd.port.mk(5) FETCH_CMD as well, I guess.
>>>
>>> Wouldn't it make more sense to provide a more sensible default in ftp(1)
>>> so it doesn't wait forever?  -w0 could do that if you really wanted, no?
>>>  
>>
>> ...which may wait forever if you run pkg_add via something like LTE modem,
>> and it decided to "renew" it's public IP.
> 
>      -w seconds
>              Wait for seconds for the remote server to connect before giving
>              up.
> 
> This should be the equivalent to curl(1)'s --connect-timeout, although I
> did not see which default value they provide.
> 
> Ours is zero, i.e. no timeout;  -w goes through strtonum(0, 200), so 3m20s
> is the maximum value.  I picked 30s as new default just to show a diff.
> 
> See util.c:timed_connect().
> 
> Works great for me.  Extra testing done like this:
> 
> 	$ time timeout 40s ftp -4 -o- http://resolves-but-drops-packets
> 	Trying 192.0.2.1...
> 	    0m40.02s real     0m00.02s user     0m00.03s system
> 
> 	$ time       ./obj/ftp -4 -o- http://resolves-but-drops-packets
> 	Trying 192.0.2.1...
> 	ftp: connect: Operation timed out
> 	    0m30.04s real     0m00.01s user     0m00.02s system
> 
> Thoughts?

Almost forgot this one.

So 30s may or may not be too short, but forever is definitely too long.

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.

job:
> FWIW, rpki-client/extern.h has a MAX_CONN_TIMEOUT of 15 seconds and a
> MAX_IO_TIMEOUT of 30 seconds for its HTTPS session handling. Those two
> values mean that TCP sessions must establish within 15 seconds and the
> connection will be dropped if no data moves for more than 30 seconds.
> Makes sense to me to use timeouts in ftp(1) calls too by default.

5m and 15s seem a little too long and short for ftp, given it has just
one knob to time out.

Perhaps 60s to be on the patient side?

I argue, anything >0s is a better default, really.

Feedback? OK?

Index: ftp.1
===================================================================
RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
diff -u -p -r1.124 ftp.1
--- ftp.1	15 Sep 2022 12:47:10 -0000	1.124
+++ ftp.1	9 Apr 2026 22:08:03 -0000
@@ -323,6 +323,7 @@ as report on data transfer statistics.
 Wait for
 .Ar seconds
 for the remote server to connect before giving up.
+The default is 60.
 .El
 .Pp
 The host with which
Index: main.c
===================================================================
RCS file: /cvs/src/usr.bin/ftp/main.c,v
diff -u -p -r1.146 main.c
--- main.c	23 Dec 2023 23:03:00 -0000	1.146
+++ main.c	9 Apr 2026 22:07:21 -0000
@@ -188,7 +188,7 @@ char macbuf[4096];
 
 FILE	*ttyout;
 
-int connect_timeout;
+int connect_timeout = 60;
 
 #ifndef SMALL
 /* enable using server timestamps by default */