[squid-users] Error Resolution (TunnelStateData::Connection:: error )
Amos Jeffries
squid3 at treenet.co.nz
Thu Jun 4 13:38:51 UTC 2015
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 at treenet.co.nz>:
>> 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
More information about the squid-users
mailing list