Download raw body.
syspatch -c : call ftp(1) with timeout
On Thu, Apr 09, 2026 at 04:11:58PM -0600, Theo de Raadt wrote: > What else is affected? > > fw_update? fw_update puts ftp in the background and times out if the size of the file doesn't change size for 12 seconds kills the download and fails. https://github.com/openbsd/src/blob/master/usr.sbin/fw_update/fw_update.sh#L133 > Surely there are more. Possibly sysupgrade? > > Klemens Nanni <kn@openbsd.org> wrote: > > > 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 */ > > > -- andrew ($do || !$do) && undef($try) ; # Master of Perl, Yoda is. Hmmmm?
syspatch -c : call ftp(1) with timeout