[squid-users] connections from particular users sometimes get stuck

[Alex Rousskov]

On 09/29/2016 02:58 AM, Eugene M. Zheganin wrote:
> This time turbodom.ru entries are present in the debug log

Yes, there are two complete HTTP transactions with that domain. One is a
407 Authentication Required and one is a 301 redirect:

> HTTP/1.1 301 Moved Permanently
...
> Location: http://turbodom.ru/index.html/

I see no relevant problems with those two transactions.


> tcpdump capture taken from a client machine:
> http://zhegan.in/files/squid/squid-stuck-client.pcap

This capture one is missing most of the second transaction packets
(tcp.stream eq 186). I do not know why tcpdump was unable to collect them.


> tcpdump capture taken from squid machine, on the interface the client
> machine is connected via:
> http://zhegan.in/files/squid/squid-stuck-server-to-client.pcap

This one has both HTTP transactions described above (tcp.stream eq 206).

It also contains a related and incomplete transaction that follows the
above redirect (tcp.stream eq 346). According to tcpdump, that
transaction starts around 13:31:26.

Squid cache log does not mention that third transaction (or that TCP
connection), probably because Squid could not accept it. There were a
few accept failures (ECONNABORTED) right around the time of that
third/missing transaction:

> 13:31:25.060 kid1| accept failure: (53) Software caused connection abort
> 13:31:25.865 kid1| accept failure: (53) Software caused connection abort
> 13:31:25.904 kid2| accept failure: (53) Software caused connection abort

The timestamps are a ~second off, but AFAICT, they are a ~second off for
successful accepts as well, so it is probably just a tcpdump logging
artifact.

In summary, your browser is probably stuck because Squid could not
accept a connection. Why did that accept call fail with ECONNABORTED? I
cannot say for sure -- the packet trace is rather dirty/misleading
(e.g., it shows the redirect packet being sent to the client _after_ the
client follows that redirect which does not make sense).

Any relevant errors in you system logs?

If you cancel browser wait and repeat the request, will it work? If this
was just a random accept failure, then it should work on the second try.
If it does not work again, then there is something more serious going on
(but you would need to collect more logs to study that).

The connection accepting code in Squid is in poor shape, but I do not
think those minor code problems affect this particular use case.

Alex.