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
