On 2024-11-17 18:41, Gaetano wrote:
We are running three squid proxy 5.5,
Please note that Squid Project does not support Squid v5. I recommend upgrading to Squid v6+ (regardless of what your Linux distribution currently ships).
on three different VMs, same number of CPUs (4), same memory, and same FS type (xfs) on Alma Linux 9. All servers are staged with Ansible and they all have the same squid.conf. workers 4 ... cache_dir ufs /var/spool/squid 512 16 256
As you probably know from that earlier thread, this combination is not supported and is likely to trigger HTTP violations and undefined behavior. The only supported cache_dir type for SMP Squids is rock.
One of those servers (always the same) crashes with this assert: kid1| assertion failed: Controller.cc:930: "EX" kid can be from 1 to 4
BTW, that bogus exception text "EX" is a bug. It was fixed in Squid v6. Squid v5.10 has a backport of that fix.
Everything works fine when we remove workers as explained in an old post about ufs and multithreading: https://lists.squid-cache.org/pipermail/squid-users/2021-November/024285.html However, why don't the other two proxies suffer from the same issue? Removing /var/spool/squid/* (+ squid -z) makes things work for a little while, then again Empty response from the server (=> assertion failed: Controller.cc:930: "EX"). So somehow it seems related to the cache and/or the response. Any ideas that could help to understand the problem?
I cannot help with understanding why undefined Squid behavior in an unsupported configuration manifests itself this particular way, but I hope that switching to a supported version and configuration helps avoid this problem.
Good luck, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
