Search squid archive

Re: keepaliveNextRequest: abandoning FD

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

 



we are seeing the same erros in our cache_log

On 12/11/2011 6:06 a.m., Alex Rousskov wrote: 
> On 11/10/2011 07:11 PM, Amos Jeffries wrote: 
>> On 11/11/2011 11:01 a.m., Alex Rousskov wrote: 
>>> Hello, 
>>> 
>>> I see thousands of these messages on busy caches: 
>>> 
>>>> 2011/11/07 05:16:23 kid1| client_side.cc(1573) keepaliveNextRequest: 
>>>> abandoning FD 6650 
>>>> 2011/11/07 05:16:27 kid3| client_side.cc(1573) keepaliveNextRequest: 
>>>> abandoning FD 9180 
>>>> 2011/11/07 05:16:28 kid5| client_side.cc(1573) keepaliveNextRequest: 
>>>> abandoning FD 6361 
>>>> 2011/11/07 05:16:28 kid6| client_side.cc(1573) keepaliveNextRequest: 
>>>> abandoning FD 3322 
>>>> 2011/11/07 05:16:31 kid2| client_side.cc(1573) keepaliveNextRequest: 
>>>> abandoning FD 7809 
>>>> 2011/11/07 05:16:32 kid3| client_side.cc(1573) keepaliveNextRequest: 
>>>> abandoning FD 121 
>>> The code says: 
>>> 
>>>> // XXX: Can this happen? CONNECT tunnels have deferredRequest set. 
>>>> debugs(33, DBG_IMPORTANT, HERE<< "abandoning"<< 
>>>> conn->clientConnection); 
>>> So, the answer to that XXX question is "yes, it can happen", at least in 
>>> older v3.2 code. Does anybody know whether there were any recent changes 
>>> that were meant to address the above? 
>> Yes the ConnStateData::stopReading() was moved to only happen when about 
>> to call tunnelStart() in client_side_request.cc instead of all CONNECT 
>> method requests. 
>> 
>> CONNECT assumes full control over the connection, but ssl-bump uses the 
>> ConnStateData. 
> 
> Understood. Since there were related changes, there is no need to change 
> the verbosity of the message now. Let's see if those warnings are still 
> there after they upgrade to more recent v3.2 releases. 
> 
> 
> Thank you, 
> 
> Alex. 
> P.S. The caches in question do not use SslBump AFAIK.

there were also a discussion from may this year

> tis 2012-05-01 klockan 08:09 -0500 skrev Guy Helmer:
>> I'm working with code I obtained from Alex that was sync'ed with trunk as of -r12082 (2012-03-07 v3.2.0.16+) and on a very busy system doing forward HTTP and HTTPS proxy (but not sslBump), I am seeing lots of these messages:
>>
>> 2012/05/01 08:50:06 kid1| client_side.cc(1611) keepaliveNextRequest: abandoning local=10.10.0.4:3128 remote=10.10.0.115:1409 FD 1113 flags=1
>> 2012/05/01 08:50:28 kid1| client_side.cc(1611) keepaliveNextRequest: abandoning local=10.10.0.4:3128 remote=10.10.0.125:1356 FD 1024 flags=1
>> 2012/05/01 08:50:28 kid1| client_side.cc(1611) keepaliveNextRequest: abandoning local=10.10.0.4:3128 remote=10.10.0.125:1357 FD 1220 flags=1
>> 2012/05/01 08:50:31 kid1| client_side.cc(1611) keepaliveNextRequest: abandoning local=10.10.0.4:3128 remote=10.10.0.125:1359 FD 1152 flags=1
>>
>> I see that there was a discussion back in November about this issue, but I am not understanding what the root cause is, and whether it is indicative of a serious problem. Any thoughts?
>
> It would be excellent if you could pair one or two such message with the
> network traffic taking place on the client connection (the client is
> remote ip:port in the message).
>
> Regards
> Henrik


we are using squid 3.2.3 and also with the latest nightly build (squid-3.2.3-20121119-r11700).

first we thought this error is some new strange behavior of squid under heavy load.
after some testing we found one error cause:

we are using ufdbguard, squid.conf:

url_rewrite_program /rzf/produkte/www/bin/ufdbguard/ufdbgclient -e allow -C -l/rzf/produkte/www/files/ufdbguard/logs


we see this error messages when there was a https-request which is blocked by ufdbguard. 
when ufdb blocks a request we do a redirect on a http-page to give the user an error response.
with https-sites this does and can not work. the browser is expecting a correct ssl answer and waits to get the right ssl-certificate from the origin server, but our http-server does answer either with http and not https and the fqdn is not correct. so in the browser I only see a general "connection error" message, not our blocked script.

this is the client side. in the cache_log we get

2012/11/21 13:09:40 kid1| client_side.cc(1602) keepaliveNextRequest: abandoning local=123.45.1.1:8080 remote=123.45.6.7:1988 FD 2247 flags=1


now the question to this long mail:

are these errors harmless, do we have to care about them? we have really a lot of these messages.
what about open connections, ssl tunnels/connects, ntlm and/or basic authentication handlers. are those connections all get closed cleanly....


mfg

Markus Rietzler
<rietzler_software/>
Rechenzentrum der Finanzverwaltung

Tel: 0211/4572-2130



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

  Powered by Linux