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.
