Subject: Re: README: process reaper committed
To: Chris G. Demetriou <firstname.lastname@example.org>
From: Ryan Ordway <email@example.com>
Date: 09/09/1998 17:18:01
On 9 Sep 1998, Chris G. Demetriou wrote:
> Todd Vierling <firstname.lastname@example.org> writes:
> > On Wed, 9 Sep 1998, Ryan Ordway wrote:
> > : > Um, that shouldn't make sshd, for instance, core-dump. If that was
> > : > happening, it dounds like (1) the device lookup code for /var/db/kvm.db is
> > : > core-dumping or (2) kvm_mkdb was making a bogus file. In either case, I
> > : > think something is broken there, and I never really liked the Berkeley-DB
> > : > format kvm.db. :>
> > :
> > : Yeah, kvm_mkdb dumped core first, which I am guessing is why the
> > : others dumped core. If someone would like, I can put it up for anon ftp.
> > Probably not a big matter, but the kvm_db stuff really needs to be rethought
> > (that was my original point :).
> huh? what are you talking about?
> approximately _none_ of those programs (other than kvm_mkdb;
> specifically i'm thinking: sshd, getty, sh, etc.) should be using the
> kvm database.
> instead, you'll note that they are all likely to use db bits, which
> have recently been updated to use pread, etc.
> I'd be interested to know:
> * what versions of kernels (and with what names) worked with what
> versions of libraries
Actually, the problem is that I first booted it, named
/netbsd.BRAHMS-4 (config BRAHMS #4)... which confused things, I am
guessing. The same kernel named /netbsd works just fine.
> I.e. an explicit list.
> To be quite honest, the lossage sounds like it could be from using a
> new libc with an old kernel, rather than anything else. (that
> shouldn't be generating seg-faults, though, I don't think.)
Nope, same libc (errr... 1.3F-ish), testing new 1.3H kernel. But
HELO... my name is rewt... you have SIGKILLed my father... prepare to vi!