[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