Are you validating your config files before committing them?? If you have about 100 clients this is the first thing to do... Either run a asciii validation script for the whole file(I can write it if you really need it) or maintain two configuration testing node (CentOS 6+7). You don't even need to apply the configurations into the a running squid, you just need to run a command like "squid -kparse -f /etc/squid/squid.conf" and it will tell you what's wrong. Let me know if you need more help. Eliezer * CC me since I'm not watching the list daily these days. ---- http://ngtech.co.il/lmgtfy/ Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Francisco Amaro Sent: Thursday, October 12, 2017 19:25 To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Squid 3.5.20 and 3.1.23 getting re-started with bogus "FATAL: Bungled" acls 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... Our ACL file is currently 7500 lines, mostly comprising of dstdomain and url_regex entries. We support a lot of costumers (about 100) and each one has a specific configuration. Mostly have while lists, and there are a few blacklists in the middle... so, not very big in terms of line numbers, but somewhat complex regarding site/VLAN entries... For security/privacy reasons I cannot share my complete configuration, namely the ACL's part, since they contain client information, but I am able to get detailed logging and/or redacted information... So... anyone has any clue what is happenning ? -- Francisco Amaro Email: mailto:famaro@xxxxxxxxx _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
