RE: Coredumping problem on Mandrake 10/2.6 kernel

[Brian Thomas]

Er, my original message included coredumps from both cfservd and
cfagent. In fact, in the reference part of your reply, you'll see you
included them. :) (I've trimmed it from mine though, for the sake of
brevity).

It doesn't appear to be tied to a particular client; I've verified that
much.

Brian

-----Original Message-----
From: Tod Oace [mailto:tod.r.oace@intel.com] 
Sent: Monday, November 08, 2004 9:25 AM
To: Brian Thomas
Cc: help-cfengine@gnu.org
Subject: Re: Coredumping problem on Mandrake 10/2.6 kernel

If there's a core dump try getting a "backtrace" using gdb. Gdb will 
need both the core dump and the cfengine binaries and sources that you 
compiled with to do that. The backtrace will show which area of code 
cfservd failed in and hopefully why.

If you don't have a core dump handy...well... Figure out how to enable 
core dumps. Maybe "unlimit" before starting cfservd?

Another idea would be to run cfservd with "-d"ebug output into a file. 
Just be careful so you don't run out of disk space. The debug output 
might be useful if some particular client is triggering the problem. 
But the backtrace will probably be more useful.  -Tod


On Nov 8, 2004, at 08:59, Brian Thomas wrote:

> I'm sure you have to answer this question all the time, and I
apologize
> for my ignorance, but... Where do I go from here? :)
>
> I mean, I understand that there can be (and were!) multiple libdb's on

> a
> system, and how the libraries from one and the headers from another
can
> cause problems. But what I don't understand is how to get around it. 
> Nor
> do I understand why I have the specific problem I do; that of cfservd
> running for hours just fine, but then deciding to crash. What in the
> header mismatch might result in that?
>
> For what it's worth, I've made sure there's only one version of libdb
> (4.x, I removed the 3.x) from the system, recompiled everything, and 
> the
> problems still persist. And, in fact, the version I compiled against
my
> own 3.x build on Friday ran ok only for about 8 hours, it crashed
> sometime during the night, so my theory about a libdb4 weirdism
doesn't
> seem to hold water.
>
> I believe this is more than just a libdb version collision problem,
> although I wholeheartedly believe libdb is still at fault in some way.

> I
> just don't know how to A) troubleshoot or B) work around it. Short of
> removing all libdb packages entirely from the system, how can I make
> sure to get a standalone cfengine compile that won't go hunting
through
> /usr/include for header files when I've specified an particular
> --with-berkeleydb path, for the purposes of entirely removing the
> possibility of a mismatch being the culprit?
>
> Again I apologize for what I know this list gets pinged about 
> regularly,
> but I've yet to find a solid answer on this, just a lot of folks
> stumbling around trying to figure out what to do.
>
> Brian
>