On Mon, Sep 14, 2009 at 06:02:26PM -0400, Daniel Richard G. wrote: > On Sun, 2009 Sep 13 09:40+0100, Mark Hindley wrote: > > > > Probably without. I think this is another concurrency/locking issue, > > but I have obviously not identified it completely correctly yet. > > Okay. Attached is a 100k-line gzipped extract of error.log, with some > bits edited for public consumption (server names and IP addresses).
Thanks, very helpful. I think I have found this. Can you verify it is fixed with this patch Mark commit 74f83f1a66ede37e0b871a84b5827011ff6c58bd Author: Mark Hindley <[email protected]> Date: Sat Sep 19 21:15:43 2009 +0100 Put the $cache_status initialisation after the -f $complete_file block to catch both situations diff --git a/apt-cacher2 b/apt-cacher2 index c33b487..e81532a 100755 --- a/apt-cacher2 +++ b/apt-cacher2 @@ -671,12 +671,8 @@ sub handle_connection { sysopen($fromfile, $cached_file, O_RDONLY) || barf("Unable to open $cached_file: $!."); unless ($cache_status && $cache_status eq 'OFFLINE') { - if (-f $complete_file) { - # not much to do if complete - $cache_status = 'HIT'; - debug_message($cache_status); - } - else { + # not much to do if complete + if (!-f $complete_file) { # a fetcher was either not successful or is still running # look for activity... if (flock($fromfile, LOCK_SH|LOCK_NB)) { @@ -692,6 +688,8 @@ sub handle_connection { debug_message('Another fetcher already working on file'); } } + $cache_status = 'HIT'; + debug_message($cache_status); } &release_global_lock; } -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
