lör 2009-07-11 klockan 20:08 +1200 skrev Amos Jeffries: > It's most visible in rotate because Squid is intended to keep running > with a hot-swap of its logs. Previously the sequence was causing two > full sets of helpers to be started, and a period of overlap before the > async closure of the old set happened.
Yes, this is what Squid-2 does. It schedules the existing set to be closed (no more new requests assigned to them), and starts a new set. The old set dies as soon as it's completed doing what it's doing at the moment.. (including statful associations). > But now that we are enforcing the number of helpers started to prevent > memory bloat the overlap prevents the new set from starting at all. Hmm.. why? haven't been much of a problem in all the years we have been doing this.. except possibly for some poorly configured SquidGuard setups with large text lists without db backends... > The safety checks in helper itself which prevent live restart attempts > are tuned to only do so on incremental helper deaths, not to wholesale > 100% loss of helpers. Yes. > Our options are: > 1 don't shutdown helpers on rotate (this ha been another open bug) > 2 make helpers code extremely aggressive to keep helpers running (at > cost of being able to detect failures) > 3 make mainRotate async Or 4, go back to don't strictly enforce the number of helpers? > Is there something I've missed that means some helpers MUST be restarted > on rotate? Helpers are restarted because their stderr is connected to cache.log in append mode. Regards Henrik
