Re: [squid-users] comm_select: kevent failure: (9) Bad file descriptor

From: Martin Solciansky <solko@dont-contact.us>
Date: Mon, 26 Mar 2007 15:18:46 +0200

> On Sun, Mar 18, 2007, Martin Solciansky wrote:
>> hello,
>>
>> we have been using squid-2.6.6 (with some security patches from higher
>> versions and the kevent patch from .11) for some time now but few weeks
>> ago
>> we started getting:
>> 2007/03/17 08:25:12| comm_select: kevent failure: (9) Bad file descriptor
>> 2007/03/17 08:25:12| Select loop Error. Retry 1
>
> I'm pretty sure I know why it is: Squid isn't removing the entries from
> the kqueue array when a filedescriptor is closed and if the filedescriptor
> isn't reused fast enough it'll end up throwing the above error.
we thought this would be the problem but the randomness and load proved it
hard to debug really.

> This error used to actually cause runtime leaks. I'm not sure if Henrik's
> recent work to mimic what libevent does has fixed it or not, but I do know
> the issue is still there.
>
> The real fix is to delay close() filedescriptors until its time to call
> kevent: on close(), modify the event in the array to be EV_DELETE, then
> close() all the filedescriptors. This is however very horrible and ugly.
> The fix I came up with for one of my private projects was to record the
> kevent array offset of the registered read/write events, if any, and
> rewrite them to be "null". Now, kqueue doesn't have any concept of an
> event slot thats to be ignored (unfortunately!) so you fake it with:
>
> * ident = 0 (fd = 0, for EV_READ and EV_WRITE filters)
> * filter = EV_READ or EV_WRITE, whatever's appropriate for what you're
> replacing
> * flags = EV_ADD | EV_DISABLE
>
> Kqueue doesn't mind if there's multiple filters added; it just overrides
> the currently registered one. The above is about as close to a NULL filter
> as you're going to get.
>
> I've done this in my test code to support loads much higher than Squid
> (~6k proxied req/sec (6k client sockets, 6k server sockets) with ~3000 to
> ~4000 concurrent connections. Its sane.)
>
> If someone wants to beat me to fixing then please, by all means. :)
well, there has been no error since I wrote to the list asking for help, it
might as well disappear the same sudden way as it appeared :-). thanks for
the insight and help.

regards,

s.
Received on Mon Mar 26 2007 - 07:18:47 MDT

This archive was generated by hypermail pre-2.1.9 : Sat Mar 31 2007 - 13:00:02 MDT