On 11/9/21 3:45 AM, Majed Zouhairy wrote: > i have ufdbguard but i don't think i have smp.. The problem, whatever it is, is unlikely to be caused by ufdbguard. My current bet is on access.log record truncation fixed in February 2020 in master/v6[1]. I do not know why that fix has not been backported to v5. I have reminded about it ~5 months ago[2], but that did not seem to help. We need to improve how backporting requests/decisions are tracked. [1] https://github.com/squid-cache/squid/commit/a03343c [2] https://github.com/squid-cache/squid/pull/332/#issuecomment-853275691 You may be able to confirm my suspicion by studying raw rejected access.log records. Please note that the problematic record might be merged with the next record/line. If my suspicions are correct, then you may be able to work around the problem by limiting the length of logged URLs. Look for ".width_max" in your logformat documentation. HTH, Alex. > the last line of squid conf are > > url_rewrite_extras "%>a/%>A %un %>rm bump_mode=%ssl::bump_mode > sni=\"%ssl::>sni\" referer=\"%{Referer}>h\"" > url_rewrite_program /usr/local/ufdbguard/bin/ufdbgclient -m 4 -l > /var/log/squid/ > url_rewrite_children 16 startup=8 idle=2 concurrency=4 queue-size=64 > > i think ufdbguard does not support squid version 5 yet, which might be > the problem > > On 11/8/21 10:42 PM, Alex Rousskov wrote: >> On 11/8/21 5:30 AM, Majed Zouhairy wrote: >>> when i run sarg >>> >>> SARG: sarg version: 2.4.0 Jan-16-2020 >>> SARG: Reading access log file: /var/log/squid/access.log >>> SARG: Log format identified as "squid log format" for >>> /var/log/squid/access.log >>> SARG: The following line read from /var/log/squid/access.log could not >>> be parsed and is ignored >>> 1636349341.484 12 10.184.0.2 NONE_NONE/400 20417 GET >>> https://zen.yandex.by/lz5XeGt8f/ir4w02684/13f5fd2qrAJ2/p_CMhOoMLrxy4M2QFtQI-HLBvD5tHT6JdGbykwp9eDzBNcrpN2RIqcyiFH9pWekXwFsAEtIMz3_5FVo5y8zXIrAwGER6-e4cM0VckNJR_CjjEd2OObzKrHDSM2ZrfFzJ9CELTSJAeFt45wBcaGm_VqdcIXKVKFp7THc-uX7PdjLGAUpRv63aKSdE2OOnMXyOt0SJK0vNXql0thIirh9cGORGu31DYR9cCKZAW9gYjiGgfTFlxfgLOitwTohOyMZzx3ZNcK_K-rk2Vb_ >>> >>> >>> .... >>> UPVydoTW1636349696.714 629 10.106.0.2 NONE_NONE/200 0 CONNECT >>> azscus1-client-s.gateway.messenger.live.com:443 - >>> HIER_DIRECT/40.74.219.49 - >>> SARG: 4 consecutive errors found in the input log file >>> /var/log/squid/access.log >>> >>> so i think the solution would be to exclude zen.yandex.by from >>> processing ? >> >> The correct solution would depend on what you are trying to accomplish >> (with sarg), but that solution is unlikely to include disabling logging >> of requests to any domains IMHO. >> >> Based on the above output (that could have been changed by multiple mail >> agents), it is difficult for me to guess what sarg did not like, but if >> you are suffering from Squid SMP workers corrupting each-other >> access.log entries, then please see Bug 5173: >> https://bugs.squid-cache.org/show_bug.cgi?id=5173 >> >> >> HTH, >> >> Alex. >> _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
