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 squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
