On 1/24/21 5:00 PM, Amos Jeffries wrote:
> On 25/01/21 10:42 am, Vieri wrote:
>>
>> After the assertion failure Squid tries to restart a few times
>> (assertion failures seen again) and finally exits.
>> A manual restart works, but I don't know for how long.
>>
>> The external script "bllookup" is probably responsible for bad output,
> That is a certainty.
>> but maybe Squid could handle it without crashing.
> As you noticed, Squid halts service only after the helper fails 10
> multiple times in a row. Before that Squid is restarting the helper to
> see if it was a temporary issue.
AFAICT, this Squid worker (rather than the helper) crashes/asserts. The
master process restarts the worker 10 times (because the worker keeps
crashing/asserting) and then gives up and kills the entire instance.
> Would you prefer Squid sucks up all the TCP/IP resources on the machine
> for clients waiting on this helper to start work?
> Or Squid to start mixing up the results so each client A lookup is
> determining the output of some other client B's transaction?
FWIW, I would prefer if Squid worker did not assert. Whether the worker
should quit when its helper fails is debatable and perhaps should be
configurable. In most environments/cases, killing the affected Squid
_transaction_ is much better than killing the Squid worker (and then
killing the entire Squid instance), but there may be exception worth
supporting (via configuration).
HTH,
Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users