Some more info: this is an ftp repo, and it's the control-channel that's just sitting there ESTABLISHED. send & recv queue are both 0. I'm guessing that http is more reliable, and should be used instead of ftp? regards, David On Mon, 9 Aug 2004, seth vidal wrote: > On Mon, 2004-08-09 at 09:21, David L. Parsley wrote: >> On Mon, 2004-08-09 at 09:01, seth vidal wrote: >>> On Mon, 2004-08-09 at 08:51 -0400, David L. Parsley wrote: >>>> I had a user report which I've now duplicated: the yum nightly cronjob >>>> hung. netstat -t -p revealed it still had an ESTABLISHED connection to >>>> a repo, and strace -p (yum process) showed it sitting and waiting in a >>>> read(6, ...), where 6 is a socket; I'm guessing it was trying to read >>>> something from the repository, but just not getting anything. Is it >>>> possible there's a transfer that's not timing out? >>>> >>> >>> Yes or they could have set retries to 0 and it's infinitely retrying. >> >> Ok, retries isn't set, so defaulting to 6; this is yum 2.0.7, btw. >> Should there be a client timeout on transfers? >> > > It's not obvious this is something that can be done without forking off > the download process. I'm not really sure how to monitor the downloader > to create some other timeout. > > -sv > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum > -- David L. Parsley Network Systems Administrator, Alfred University "If I have seen further, it is by standing on ye shoulders of giants." - Isaac Newton
