From: Job Snijders <job@bsd.nl>
Subject: Re: syspatch -c : call ftp(1) with timeout
To: Klemens Nanni <kn@openbsd.org>
Cc: Antoine Jacoutot <ajacoutot@bsdfrog.org>, Matthieu Herrb <matthieu@openbsd.org>, tech@openbsd.org
Date: Tue, 24 Feb 2026 15:45:02 +0000

On Sat, Feb 21, 2026 at 05:30:14PM +0000, Klemens Nanni wrote:
> 21.02.2026 15:00, Antoine Jacoutot пишет:
> > On Sat, Feb 21, 2026 at 08:48:58AM +0100, Matthieu Herrb wrote:
> >> 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?

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.

Kind regards,

Job