Re: ftp -q 60 not working (well)

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Mon, Nov 30, 2020 at 08:19:00AM -0500, Mouse wrote:
> > The hangs from the last two weeks look like this (in ps):
> 
> > pkgmastr  18764  0.0  0.0  33012   4748 ?       I    15Nov20    0:00.02 /usr/bin/ftp -q 60 -o tzinfo-2.0.3.gem https://rubygems.org/gems/tzinfo-2.0.3.gem                                                                                                                                                       pkgmastr  26119  0.0  0.0  30460   4752 ?       I     9Nov20    0:00.01 /usr/bin/ftp -q 60 -o rack-cache-1.12.1.gem https://rubygems.org/gems/rack-cache-1.12.1.gem
> 
> > I.e. there is a time limit of 60s but the job runs for two or three
> > weeks without apparent progress. This looks like a bug in ftp(1), or?
> 
> According to ftp.n.o's manpage, -q is not a time limit on the transfer.
> It is a limit on the time ftp will let the connection be "stalled",
> whatever that means.
> 
> The code is unclear enough a quick skim doesn't tell me exactly what
> "stalled" means; I would guess it means without any data being received
> - or other progress being made, if expecting something other than data,
> such as a data channel connection coming up.
> 
> It might be interesting to look at the underlying TCP traffic.  I
> suspect something has caused it to slow to a crawl but not quite stop.
> (I've seen such behaviour from TCP on a few occasions, though I haven't
> understood any such occasion well enough to suggest a possible cause.)

The server would have to do this on purpose -- the whole file
tzinfo-2.0.3.gem is 78336 bytes long, and ruby-rack-cache-1.12.1.gem
is only 29184 bytes.

So while I think it would be possible that that is the explanation, I
still suspect a bug in the code instead.
 Thomas