new ovdb feature

[Heath Kehoe]

>
>> If your nnrpds still lock up even when using the ovdb_server, then
>> we can assume the problem lies not with BerkeleyDB; as BerkeleyDB
>> is not used at all in those nnrpds.
>
>Except, using the stock k0deZ (and guessing how the k0deZ work here),
>when all the ovdb_swerver processes coredump (must look for one of
>these cores, it'll probably help) and then I see the rc: connection
>refused message, that I assume defaults to normal access.  Unless I
>hack the k0deZ to return an error at that point...
>

Get me a stack trace; or at least where the SEGV happens.
I'll bet there's a silly dainbread mistake somewhere with a
two-line fix.

If the readserver is not available, it will revert to normal access.
It's pretty easy to add an option to prevent that.  But for now, in
ovdb.c, you can put "return FALSE;" in place of the "clientmode = 0;"
right after the client_connect() in ovdb_open().

>
>> Sounds like the ovdb_server is failing to start properly at all.
>> Hmm... it's possible that my multiple-processes-sharing-a-listen-socket
>> technique is not as portable as I'd hoped.
>
>I see the same problems with it that I did with xinetd when I was
>using that to limit number of parallel user connections and an
>aborted attempt to do rate limiting -- at least with Slowaris, when
>I sent a signal to read updated config parameters, it tried to re-
>open the listening socket but failed, until time passed.  Which is
>also why out-of-the-box it didn't work for rate limiting, since it
>disabled the service and wasn't able to restart it.
>

Except that the listen socket is never closed or reopened...

-h