help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coredumping problem on Mandrake 10/2.6 kernel


From: Tod Oace
Subject: Re: Coredumping problem on Mandrake 10/2.6 kernel
Date: Mon, 8 Nov 2004 09:36:15 -0800

On Nov 8, 2004, at 09:28, Brian Thomas wrote:

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. :)

Excellent! :)  <blush>

LastSeen()... I actually had trouble with that on Redhat 7.1. Exchanged a bunch of emails with Mark and we guessed that Redhat 7.1's resolver has a problem. My backtraces looked different than yours, but as soon as I disabled LastSeen() things got stable again.

Mark added a "LastSeen = ( off )" feature for cfservd.conf. Maybe that'll help you too?

I'd be interested if you or anyone figure out anything on this. I want to use LastSeen but I'll probably be waiting until I do an OS upgrade (next quarter) before I try it again. -Tod


 (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



--
Tod Oace, Intel Corporation <tod@intel.com>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]