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. 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. :) Adrian
