Search squid archive

Re: Error Resolution (TunnelStateData::Connection:: error )

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/06/2015 1:18 a.m., Iruma Keisuke wrote:
> Thank you Amos.
> 
> 2015-06-02 23:07 GMT+09:00, Amos Jeffries <squid3@xxxxxxxxxxxxx>:
>> On 2/06/2015 9:15 p.m., Irimajiri keisuke wrote:
>>> Dear all,
>>>
>>> I have to build a proxy server by using the squid.
>>> The number of clients is 400 people.
>>>
>>> I do not know the cause of the error message that appears in the
>>> cache.log.
>>> In the weekday, I have come up with an error every few hours 8:00 to
>>> 18:00.
>>> Access concentration I look like does not matter.
>>>
>>> [cache.log error message]
>>> 2015/05/11 13:37:24| TunnelStateData::Connection:: error : FD 610:
>>> read/write failure: (110) Connection timed out
>>>
>>> Why I want to know whether this error has occurred.
>>
>> Yes it has occured. You would not be seeing it otherwise.
>>
>>> Also, I want to know the impact on the user.
>>
>> The user who is causing the problem is probably not impacted at all.
>> Every other user sharing the proxy is impacted by the reduction in
>> available network socket, memory and CPU resources.
>>
> It seems to be no abnormality in the state of network sockets and
> memory and CPU.
> Is it safe to ignore this error?

If you think your service is operating fine. It does mean the proxy has
a lower threshold of tolerance for network congestion than normal.


>>>
>>> [squidclient mgr:filedescriptor]
>>> Every five minutes record
>>> extract FD610
>>>
>>> It looks like an error has occurred in the use to which the terminal
>>> of xxx.xxx.2.115 user.
>>> Is it a problem of communication of the user and the proxy?
>>>
>>
>> Nothing happened on a TCP conection for a long time. It was closed by
>> the networking sub-systems somewhere between Squid and the client.
>>
> 
> Do error is not out on the web browser?
> Could you detailed information about TCP state and the state of the
> user when an error has occurred.

It might be, or it might not be. Others before you who noticed the same
messages have a mixed set of reasons found for it. Some was Chrome
browser happy eyeballs algorithm leaking its second connection until it
got dropped by the network TCP stack. Some it was F5 load balancers
breaking. Others it was NAT timeout in users home routers. Some have not
bothered to dig deep so it may be other causes.

All that is certain is that something between Squid and user is closing
the connection while it is in an HTTP idle state.

> 
>>> Active file descriptors:
>>> File Type   Tout Nread  * Nwrite * Remote Address        Description
>>> ---- ------ ---- -------- -------- ---------------------
>>> ------------------------------
>>>  610 Socket  893    39494*   50228  xxx.xxx.xxx.162:443
>>> outlook.office365.com:443       2015/05/11_13:08:29
>>>  610 Socket 86329   45754*  103329  xxx.xxx.6.141:50174   Reading next
>>> request         2015/05/11_13:13:29
>>>  610 Socket 86258    6516*   13975  xxx.xxx.2.115:50820   Reading next
>>> request         2015/05/11_13:18:29
>>>  610 Socket 85958   12472*   34531* xxx.xxx.2.115:50820   Reading next
>>> request         2015/05/11_13:23:29
>>>  610 Socket 85657   12472*   34531* xxx.xxx.2.115:50820   Reading next
>>> request         2015/05/11_13:28:29
>>>  610 Socket 85357   12472*   34531* xxx.xxx.2.115:50820   Reading next
>>> request         2015/05/11_13:33:29
>>>  610 Socket 86336    3652*    8003  xxx.xxx.3.152:50817   Reading next
>>> request         2015/05/11_13:38:29
>>>
>>> [access.log]
>>> I do not see suspicious error log I tried to extract the address
>>> xxx.xxx.2.115.
>>>
>>> Please tell me a good idea toward someone solve.
>>
>> Please provided additional details:
>>  * Squid version
>>  * Squid configuration
>>
>>
>> I suspect you have a quite old verion of Squid. That particular error
>> message does not even exist in the code any more. The current releases
>> display much more TCP details about the connection where the error occured.
> 
> squid version is squid-3.1.10-29.
> This is the latest version that RedHat is delivering.

Ah, yes RHEL policy of not updating unless explicit bug reports exist
and supporting things for 10 years+ >

You may be interested in the official unofficial packages (accepted by
the Squid Project and community as reasonable packages for use, but not
RHEL official supported).
<http://wiki.squid-cache.org/KnowledgeBase/RedHat>


> 
> [squid.conf]
> ------------------------------------
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
> acl localnet src 10.0.0.0/8	# RFC1918 possible internal network
> acl localnet src 172.16.0.0/12	# RFC1918 possible internal network
> acl localnet src 192.168.0.0/16	# RFC1918 possible internal network
> acl localnet src fc00::/7       # RFC 4193 local private network range
> acl localnet src fe80::/10      # RFC 4291 link-local (directly
> plugged) machines
> acl SSL_ports port 443
> acl Safe_ports port 80		# http
> acl Safe_ports port 21		# ftp
> acl Safe_ports port 443		# https
> acl Safe_ports port 70		# gopher
> acl Safe_ports port 210		# wais
> acl Safe_ports port 1025-65535	# unregistered ports
> acl Safe_ports port 280		# http-mgmt
> acl Safe_ports port 488		# gss-http
> acl Safe_ports port 591		# filemaker
> acl Safe_ports port 777		# multiling http
> acl CONNECT method CONNECT
> http_access allow manager localhost
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow all

!!!! Open proxy !!!


> http_port 192.168.1.1:8080
> hierarchy_stoplist cgi-bin ?
> coredump_dir /var/spool/squid
> refresh_pattern ^ftp:		1440	20%	10080
> refresh_pattern ^gopher:	1440	0%	1440
> refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
> refresh_pattern .		0	20%	4320
> 
> cache_mem 2048 MB
> cache_store_log none
> visible_hostname unknown
> request_header_access X-FORWARDED-FOR deny all
> request_header_access Via deny all
> max_filedesc 10240
> ipcache_size 10240
> -----------------------------------------------
> 
> Please let me ask further questions
> Are these has to do with the error?
> http://www.squid-cache.org/Doc/code/tunnel_8cc_source.html
> 
> 472 TunnelStateData::Connection::error(int const xerrno)
> 473 {
> 474  /* XXX fixme xstrerror and xerrno... */
> 475  errno = xerrno;
> 476
> 477  debugs(50, debugLevelForError(xerrno), HERE << conn << ":
> read/write failure: " << xstrerror());
> 478
> 479  if (!ignoreErrno(xerrno))
> 480  conn->close();
> 481 }
> 
> 536  /* Bump the dest connection read timeout on any activity */
> 537  /* see Bug 3659: tunnels can be weird, with very long one-way transfers */
> 538  if (Comm::IsConnOpen(to.conn)) {
> 539  AsyncCall::Pointer timeoutCall = commCbCall(5, 4, "tunnelTimeout",
> 540  CommTimeoutCbPtrFun(tunnelTimeout, this));
> 541  commSetConnTimeout(to.conn, Config.Timeout.read, timeoutCall);
> 542  }
> 543
> 

Possibly, but predates all that codes existence.

Amos

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users





[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux