[squid-users] assertion failed: Controller.cc:930: "EX"

[Alex Rousskov]

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.