new ovdb feature

[Heath Kehoe]

>On 14 Nov 2000, Heath Kehoe wrote:
>
>> This update is now available.  It has been committed to -current,
>> and should appear in the Nov 14 snapshot.  Also, a patch for 2.3.x
>
>Yay, you can't imagine how happy this makes me, as our buffindexed
>test started to fall over a couple days ago, and I've applied it
>and am trying to get familiar with it (will it support two nnrpds
>listening on two different ports; if so, I b0rke something that I
>need to track down)...

Uh, it should work with two nnrpds; as long as you still have only
one ovdb database.


>
>Anyway, while trying to track down what's going on here, I happened
>to notice that while I took down the listening nnrpd many hours ago,
>a `ps' still reveals leftover nnrpd processes that have been present
>for a couple days.  Or more.

Existing nnrpds shouldn't affect ovdb_server or new nnrpds that
are connected to ovdb_server.


>
>Yes, Slowaris 2.7.  I wonder if these lingering nnrpds will still be
>present and will cause me problems with ovdb again...  I also wonder
>if anyone else sees such ancient nnrpds...

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.  The good news is, if that
happens, the stuck nnrpd won't wedge the whole works.  You can
safely off it with a kill -9.


>[...]
>
>Oh, I have things working now -- apparently, if something bails out
>during `rc.news start', invoking it a second time did bad things so
>that I was getting a `cant connect to swerver' message.  However,
>I am seeing several occurrences of two errors: OVDB: rc: cant read:
>Bad file number, or: cant write: B0rken pipe.  But I only started
>things a few minutes ago, so...
>
>Woo hoo, now they just got all <defunct>like, and I'm getting a
>timeout waiting for swerver error.  This is with the mem-leak-fixed
>source .c file you announced a few hours ago.  Time to go digging...
>

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.

-heath