On Thu, Apr 22, 2010 at 1:07 PM, Jeremy C. Reed <r...@reedmedia.net> wrote:
> On Wed, 14 Apr 2010, Jan Lentfer wrote:
>
>> After playing around with this back and forth for a while I think I found
>> the problem. Well, not actually the problem but a bypass to the BIND
>> crashes. When building any version of BIND from base autoconfigure will
>> enable kqueue support which seems to lead to this behaviour. I patched the
>> Makefiles in pkgsrc to disable kqueue and both bind95 and bind96 have now
>> my passed my queryperf tests that would originally let them crash within
>> minutes or even seconds. I will now upgrade my home server to this
>> kqueue-disabled version of BIND and report later. This are the patches:
>>
>> ----------------------------------------
>>
>> diff --git a/net/bind95/Makefile b/net/bind95/Makefile
>> index bb97183..ff2a37b 100644
>> --- a/net/bind95/Makefile
>> +++ b/net/bind95/Makefile
>> @@ -88,3 +88,7 @@ CONFIGURE_ARGS+= --disable-threads
>> .else
>> CONFIGURE_ARGS+= --enable-threads
>> .endif
>> +
>> +.if ${OPSYS} == "DragonFly"
>> +CONFIGURE_ARGS+= --disable-kqueue
>
> Can you please report your problems with kqueue on DragonFly to
> bind9-bugs
> AT
> isc.org?
>
> Or maybe better yet, we should look to see if the problem is kqueue on
> DragonFly and not BIND 9 related.
>
> If you have any core dumps, back traces or logs related to your
> problems, please share them. Thanks!
>
>
> (I work for ISC.)
>
>
Jeremy,
[13:02] <@corecode> what's wrong with bind?
[13:02] <@thesjg> corecode: it doesn't account for semantic
differences between kevent and select/poll
[13:02] <@corecode> ah?
[13:02] <@corecode> which are?
[13:03] <@thesjg> in kevent, if you register an fd, an event happens
on that fd, and you delete that fd from the watchlist, then pull out
your events, you will get that event on your already deleted fd
[13:03] <@thesjg> because it happened before you deleted it
[13:04] <@thesjg> select and poll you won't, obviously, because there
isn't an in-kernel watch list
[13:04] <@thesjg> BIND sets a flag after it deletes a fd from the
watch list and asserts when it gets an event for that fd
[13:04] <@corecode> oh
[13:05] <@corecode> i thought it would remove the events
[13:05] <@corecode> the kernel
[13:05] <@thesjg> corecode: i checked freebsd source and it seems to
share our semantics
[13:05] <@thesjg> corecode: which i think are correct (there was an
event that occured while the fd was in the watch list)
[13:06] <@thesjg> corecode: if one wanted it to exhibit poll-like
behavior i think the right approach would be to add a flag, which
would be ok i think
We were just talking about this on IRC. I was going to work up a test
case rather than a patch as I didn't know how willing the ISC was to
accept external patches. I can do either.
Sam
