[squid-users] Squid 3.5.20 and 3.1.23 getting re-started with bogus "FATAL: Bungled" acls

Amos Jeffries squid3 at treenet.co.nz
Fri Oct 13 03:16:52 UTC 2017


On 13/10/17 05:24, Francisco Amaro wrote:
> Hello all,
> 
> We are running stock CentOS 6 and CentOS 7 Squid builds, patched to the 
> latest version, 3.1.23 and 3.5.20.
> We have several machines, running on separate locations, with an ACL 
> file unique to all, that get's pushed to all machines using an homemade 
> script. So local configuration (interfaces, cache locations, etc) is one 
> file, and the bulk of the ACL's are included on
> a separate file, that is the same on all servers.
> 
> For some time now, but getting more frequent on the last couple of 
> weeks, we have been getting errors on our cache.log about bogus ACL's, 
> forcing a squid restart. This happens on configuration reloads, which we 
> do very frequently,  maybe 10-20 times a day.
> 
> On CentOS 6, the most frequent error is :
> 
> FATAL: Bungled (null) line 203: icap_retry deny all
> 
> We do not use icap_retry, it is missing from the config file, but this 
> seems to be fixed on 3.2.4:
> 
> Changes to squid-3.2.4 (03 Dec 2012):
> - Remove 'Bungled' warning on missing component directives
> 
> On CentOS 7, the most frequent error is :
> 
> FATAL: Bungled (null) line 3: sslproxy_cert_sign signTrusted all
> 
> Now this one even has a bug entry, and was fixed on 3.3.5:
> 
> Changes to squid-3.3.5 (20 May 2013):
> - Bug 3744: squid terminated: FATAL: Bungled (null) line 3: 
> sslproxy_cert_sign signTrusted all
> 
> But we are still seeing it on 3.5.20...
> 
> Now what is even more weird is that besides that, we are getting what 
> seem complete random bogus entries, like this ones:
> 
> FATAL: Bungled /etc/squid/squid_acls line 11796: acl xyz_allow_url
> FATAL: Bungled /etc/squid/squid_acls line 10905: acl abc_url108 dstdomai
> 
> FATAL: Bungled squid_acls line 10033: http_access allow def_
> FATAL: Bungled squid_acls line 9605: http_access allow ms_src_teste ms_t
> FATAL: Bungled squid_acls line 11025: http_access allow xpto
> 
> The problem is that these lines are 100% correct , they are not 
> "bungled" at all,  it seems the parser as some issue with it.
> 
> Each time we get an error like this, Squid does a full restart, and that 
> on CentOS 6 is time consuming, maybe 2-3 minutes, time enough for our 
> users reaching for the Helpdesk tickets... On CentOS 7, since the 
> restart is very fast, we do not have many complaints.....

Eliezer provides some more up to date packages for CentOS 
<https://wiki.squid-cache.org/KnowledgeBase/CentOS#Squid-3.5>


> So... anyone has any clue what is happenning ?
> 

Two things come to mind:

* non-ASCII characters in your config file. That used to be a regular 
problem with cut-n-paste on some systems.



* the wrong binary running somehow.

Try shutting Squid down completely then restarting it.

If that does not work by itself you can repeat with a re-install after 
the shutdown.


Amos


More information about the squid-users mailing list