reassign 529794 apt severity 529794 important merge 529794 465572 thanks #include <hallo.h> * Albin Tonnerre [Thu, May 21 2009, 07:07:51PM]:
> > and send me that logfile. You can also increase the debug level of the > > server, see apt-cacher-ng manual, section 7.5ff. The extra log output > > goes to the file apt-cacher.err in the log directory. > > 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 - 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 Regards, Eduard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
