[squid-users] Re: keepaliveNextRequest: abandoning FD

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
Received on Wed Nov 21 2012 - 12:14:20 MST