[same as previous message, except cc'ing the correct bug] No luck. Same or worse behavior as before.
During aptitude update apt-cacher shows as using most CPU. Throughput well below my link speed (this is the part that might be worse than before). During aptitude upgrade, while pulling in debs apt-cacher shows as using most cpu. The offending thread says still lists apt-cacher as the command line, but has [libcurl] afterwards. Ross P.S. Your last message appeared to cc submit but not the bug itself. On Tue, 2009-07-21 at 15:34 +0100, Mark Hindley wrote: > On Sat, Jun 20, 2009 at 11:09:45AM -0700, Ross Boylan wrote: > > Package: apt-cacher > > Version: 1.6.8 > > Severity: normal > > > > Often, pretty much all the time these days, apt-cacher uses 50-75% of my > > CPU when aptitude is downloading packages (or, I think, doing an update). > > Could you try this patch > > Cheers > > Mark > > commit 9794616b17d6afb85aa1eca73e9f21cd9c18b1aa > Author: Mark Hindley <[email protected]> > Date: Tue Jul 21 15:25:29 2009 +0100 > > Possible fix for #533830 > > diff --git a/apt-cacher2 b/apt-cacher2 > index 48741b6..df91fc3 100755 > --- a/apt-cacher2 > +++ b/apt-cacher2 > @@ -1152,7 +1152,9 @@ sub connect_curlm { > eval { > local $SIG{__DIE__} = 'IGNORE'; # Prevent log verbosity > local $SIG{ALRM} = sub { > - unless ($active_handles) { > + unless ($active_handles || $select->can_read(0)) { > + $select->remove($server); > + $server->close; > die "libcurl inactive\n"; > } > else { > @@ -1227,11 +1229,11 @@ sub connect_curlm { > } > } > }; > + unlink ($cfg->{libcurl_socket}); > if ($@ and $@ !~ /libcurl inactive\n/) { > die "Libcurl alarm error: $@" > } > debug_message("Libcurl thread inactive. Exiting"); > - unlink ($cfg->{libcurl_socket}); > exit(0); > } > else { > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
