[squid-users] large downloads got interrupted

[Amos Jeffries]

On 30/06/2016 2:24 a.m., Eugene M. Zheganin wrote:
> Hi.
> 
> On 29.06.16 05:26, Amos Jeffries wrote:
>> On 28/06/2016 8:46 p.m., Eugene M. Zheganin wrote:
>>> Hi,
>>>
>>> recently I started to get the problem when large downloads via squid are
>>> often interrupted. I tried to investigate it, but, to be honest, got
>>> nowhere. However, I took two tcpdump captures, and it seems to me that
>>> for some reason squid sends FIN to it's client and correctly closes the
>>> connection (wget reports that connection is closed), and in the same
>>> time for some reason it sends like tonns of RSTs towards the server. No
>>> errors in logs are reported (at least on a  ALL,1 loglevel).
>>>
>> It sounds like a timeout or such has happened inside Squid. We'd need to
>> see your squid.conf to see if that was it.
> Well... it quite long, since it's at large production site. I guess you
> don't need the acl and auth lines, so without them it's as follows
> (nothing secret in them, just that they are really numerous):

Okay. I was kind of hoping you had set some of the timeouts to a
unusually low value. Since its all default, then I think its one of the
much more difficult bug related issues.

<snip>
> 
> The download I test this issue on is:
> - a large iso file, 4G from Yandex mirror
> - goes via plain http (so no sslBump)
> - client is authenticated using basic authentication
> - you can see a delay pools in squid.config, but this is just a
> definition, no clients are assigned into it
> 
> 
> When connection is closed the client receives FIN sequence, and squid
> sends a loooot of RSTs towards target server I'm downloading the file from.
> 
>>
>> What version are you using? there have been a few bugs found that can
>> cause unrelated connections to be closed early like this.
> I noticed this problem on squid 3.5.11, but it's reproducible on 3.5.19
> as well.
> 
>> Screen dump of packet capture does not usually help. We usually only ask
>> for packet captures when one of the dev needs to personally analyse the
>> full traffic behaviour.
>>
>> A cache.log trace at debug level 11,2 shows all the HTTP messages going
>> through in an easier format to read. There might be hints in there, but
>> if it is a timeout like I suspect probably not.
> Well... do you need it already ? I should say that it will be way huge.
> May be there's a way to grep only the interesting parts ?
> 

Okay, I wasn't suggesting you post it here. Its likely to be too big for
that.

I would look for the messages about the large object, and its FD. Then,
for anthing about why it was closed by Squid. Not sure what tha would be
at this point though.
There are some scripts in the Squid sources scripts/ directory that
might help wade through the log. Or the grep tool.

Amos