[squid-users] problem in squid log

[Alex Rousskov]

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.
>>