On Thu, May 21, 2009 at 09:25:00PM +0200, Eduard Bloch wrote : > > > Log files attached. I also noticed that although apt always seemingly dies > > when > > installing libxfixes3, it doesn't die when trying to install this package > > alone. > > It however fails when installing a large number of packages. > > Thank you. I found nothing unusual in the log except of one detail: apt > stopped sending requests after few dozens for no apparent reasons. I do > not see any connection to the files you mentioned... but I have a > theory: > > Apt's client sucks and does not send a proper Connection: header, > neither does it reliably terminate the connection at the end if the > server doesn't do it by itself. After some trouble with that, I > implemented a heuristic in recent versions, it looks at the request > pipeline and assumes that APT is done when all data is delivered and > there are no more requests in the queue at this moment. BTW, I also > don't like apt's processing engine, IIRC it's constructed around some > select-triggered clock instead of controlling the queue by the > actual data events. > > Anyhow, my assumption is following: > - your cache server is pretty fast > - your client machine is not so fast or loaded, or maybe the (kernel) > task scheduler timings or some other component might introduce weird > temporary effects
It's the same machine, I use a local apt-cacher-ng as packages cache for sbuild > - for the above reasons, apt fails to send enough requests. The cacher > server closes the connection, apt's http client goes nuts and dies. > See Bug 465572 for similar symptoms. > > Possible workaround: set the maximum size of pipeline to something > insane, i.e. -o Acquire::http::Pipeline-Depth=12345 > That does seem to work, thank you very much Regards, -- Albin Tonnerre
signature.asc
Description: Digital signature
