Nope, sorry, I don't think so - I looked at the log and saw the gdbm
initializing message with no errors...
"It claims not to know where GUN gdbm is." - no, it's in the default
location. It should be setting GDBM_ROOT to "Standard Installation" for the
report (there must be something odd with configure.in - I don't see it,
but...). But the header and library are still there and work fine...
"It also tells me when I specify where gdbm (compiled) source is, that
something is wrong with
it." -- it doesn't want the source, it want's the executable (e.g. the
default is something like /usr, so it uses /usr/include and /usr/lib for the
header and libraries respectively)
"I will try to install the snapshot you suggested" good... I think it will
solve your problem...
"but out of curiosity, what version of gdbm are you running?" -- wait one --
[bstrauss@tigger ntop-current]$ rpm -q gdbm
gdbm-1.8.0-10
on one machine and the unmodified /usr/src/sources/gdbm-1.8.0.tar.gz on
the other...
So the problem is not gdbm. What you haven't posted are the log files ntop
creates (either on the console or in the syslog depending on the -L flag. I
suspect it will show that ntop started and then just dies - and that's a
known problem in the 2.0 base, having to do with hashing and a couple of
other places. The snapshot should fix that (and introduce other areas of
fun).
Let me correct one mis-understanding on your part. Just because you didn't
do anything, doesn't mean nothing changed. ntop is incredibly sensitive to
what is happening on the network, 99% of which is invisible to you.
* Somebody starts a Quake server and all of a sudden the traffic you see
becomes 10x and all most exclusively UDP between a set of machines with no
reverse DNS lookup.
* Somebody, configuring his new cable modem - now dhcp based - mungs the
dhcpclient-entry-hooks script and requests 100s of address from the server
all at once. ntop sees these as 100s of new machines it has to track...
The # of active machines on the network affects the hashing tables and they
resize themselves dynamically as more or fewer machines are "active". You
changed nothing, but ntop now has a different set of flows to track... It
could be executing code that - previously - was never executed. And the
hash resize was a problem in 2.0 released - so if your network is now
"busier" than last month, each time ntop starts up, it goes through the same
growth of the hash tables and hits the problem. It could be that...
I'm mildly suspicious that you could have a corrupted gdbm file - maybe
delete the .dbs (mine are in /usr/share/ntop) - as ntop will re-create them
on startup.
Otherwise, check the FAQs at http://snapshot.ntop.org for instructions on
how to run ntop under gdb to capture the stack trace when it bombs...
Detailed analysis below...
-----Burton
==========================
Let me take a closer look, since you did post all the stuff :-)
gdbm did install:
Libraries have been installed in:
/usr/local/lib - and that's a pretty standard location...
The ./configure tests worked:
checking for gdbm.h... yes
checking for gdbm_open in -lgdbm... yes
I'm pretty sure it did find it...
the echo (in congiure) is
GNU gdbm in : ${GDBM_ROOT}
but it's blank if you don't give --with-gdbm-root= a value - although it
still looks in default locations... at one point it should set it to
"standard location", so there may be a bug in the Configure.in file.
Initially it sets it to the value you gave or blank.
# Check whether --with-gdbm-root or --without-gdbm-root was given.
if test "${with_gdbm_root+set}" = set; then
withval="$with_gdbm_root"
GDBM_ROOT="$withval"
else
GDBM_ROOT=
fi
But later on it's supposed to set it to "standard installation" (here is
the whole block from configure.in - that's sometimes clearer):
dnl>
dnl> The GNU database manager gdbm (MANDATORY)
dnl> check for `gdbm_open' in -lgdbm
dnl>
dnl> order as follow
dnl> 1. user defined gdbm development tree
dnl> 2. standard installation in /usr/lib and /usr/include respectively
dnl> 3. default package installation in /usr/local/lib and
/usr/local/include respectively
dnl> 4. gdbm development tree under the same ntop's root source directory or
in a subdir
if test ".${GDBM_ROOT}" != .; then
AC_MSG_CHECKING([for the GNU Database Manager Library gdbm (required
package)])
if test -d $GDBM_ROOT &&
test -r $GDBM_ROOT/libgdbm.a &&
test -r $GDBM_ROOT/gdbm.h; then
GDBM_ROOT=`cd ${GDBM_ROOT} && pwd`
CORELIBS="${CORELIBS} -L$GDBM_ROOT -lgdbm"
INCS="${INCS} -I$GDBM_ROOT"
AC_DEFINE(HAVE_GDBM_H)
AC_MSG_RESULT([found in $GDBM_ROOT])
else
AC_MSG_RESULT([not found in ${GDBM_ROOT}])
AC_MSG_RESULT([ *** FATAL ERROR *** ])
AC_MSG_RESULT([ It looks that you don't have some files needed to use
the gdbm library.])
AC_MSG_RESULT([ Please check the source tree, compile and, optionally,
install the software.])
AC_MSG_RESULT([ When finished please re-run this program.])
AC_MSG_RESULT([ You can download the latest source tarball at
http://www.gnu.org/software/gdbm/gdbm.html])
AC_MSG_ERROR([ The GNU Gdbm Library development tree seems corrupted or
incomplete!])
fi
else
AC_HAVE_HEADERS(gdbm.h)
AC_CHECK_LIB(gdbm, gdbm_open, CORELIBS="$CORELIBS -lgdbm")
fi
if test ".`echo $CORELIBS | grep gdbm`" = .; then
if test -d /usr/local &&
test -r /usr/local/lib/libgdbm.a &&
test -r /usr/local/include/gdbm.h; then
GDBM_ROOT="/usr/local"
CORELIBS="${CORELIBS} -L$GDBM_ROOT/lib -lgdbm"
INCS="${INCS} -I$GDBM_ROOT/include"
AC_DEFINE(HAVE_GDBM_H)
AC_MSG_RESULT([found in $GDBM_ROOT])
elif test -r /usr/lib/libgdbm.a &&
test -r /usr/include/gdbm.h; then
GDBM_ROOT="/usr"
CORELIBS="${CORELIBS} -lgdbm"
AC_DEFINE(HAVE_GDBM_H)
AC_MSG_RESULT([found in $GDBM_ROOT])
else
AC_CHECK_LIB(gdbm, gdbm_close)
if test "$ac_tr_lib" != "HAVE_LIBGDBM"; then
AC_MSG_RESULT([ *** FATAL ERROR *** ])
AC_MSG_RESULT([ It looks that you don't have the libgdbm
distribution installed.])
AC_MSG_RESULT([ Download, compile and, optionally, install it.])
AC_MSG_RESULT([ When finished please re-run this program.])
AC_MSG_RESULT([ You can download the latest source tarball at
http://www.gnu.org/software/gdbm/gdbm.html])
AC_MSG_ERROR([ The GNU Gdbm Library development tree seems
corrupted or incomplete!])
else
GDBM_ROOT="standard installation"
fi
fi
fi
The test for gdbm.h is around 5355 in my configure - if you give it a value,
it looks there, otherwise it uses the compiler to do a test compile. But if
those tests fail, it gives errors. So the 2nd 'checking for' above means it
was able to compile and run w/o error a small test program using gdbm...
#line 5429 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char gdbm_open();
int main() {
gdbm_open()
; return 0; }
ACTION: check in your config.h for a HAVE_GDBM_H line (#define HAVE_GDBM_H
1) but I'm 100% sure you have it set...
Then check in initialize.c around 443... if you got the initializing message
and no error, it was able to open and connect to databases...
-----Burton
-----Original Message-----
From: Richard Daniel Farina [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 22, 2002 10:37 AM
To: [EMAIL PROTECTED]
Subject: Re: RE: [Ntop-dev] ntop2.0
I assume, and quite possibly incorrectly, that gdbm is the problem
because:
This is your ntop 2.0.0 configuration:
Host System Type : i686-pc-linux-gnu
Compiler (cflags) : gcc -g -O2 -pipe -DHAVE_CONFIG_H
Include path : -I/usr/local/include -I/root/ntop/gdchart0.94c
-I/usr/local/ssl/include
System Libs : -lpthread -lresolv -lnsl -ldl
Core Libs : -L/usr/local/lib -lpcap -lgdbm
Additional Libs : -L/usr/lib/mysql -lmysqlclient -lcrypt -lm
-L/root/ntop/gdchart0.94c -lgdchart -L/root/ntop/gdchart0.94c/gd-1.8.3
-lgd -L/root/ntop/gdchart0.94c/gd-1.8.3/libpng-1.0.8 -lpng
-L/root/ntop/gdchart0.94c/zlib-1.1.3 -lz -L/usr/local/ssl/lib -lssl
-lcrypto
LBL pcap in : /usr/local
GNU gdbm in :
MultiThread mode : yes
Install path : /usr/local
Now type 'make' or 'gmake' (GNU make) on *BSD and Solaris
systems to build ntop 2.0.0.
It claims not to know where GUN gdbm is. It also tells me when I
specify where gdbm (compilied) source is, that something is wrong with
it. I will try to install the snapshot you suggested, but out of
curiousity, what version of gdbm are you running?
Rick Farina
Miami University
Systems Analysis Major
Burton M. Strauss III wrote:
>In your web page, you have this...
>
>>>I think it has something to do with gdbm. Let's try to tell ntop where
to
>find gdbm.
>>>Okay, first I "make distclean".
>>>Now let's tell ntop where gdbm is.
>./configure --with-gdbm-root=/root/ntop/gdbm-1.8.0.
>>>Well, I have not idea what happened there! I just made and installed
gdbm,
>and it says there is something wrong? I'm confused.
>>>Maybe if I try to enable the debug.
>./configure --enable-debug --with-gdbm-root=/root/ntop/gdbm-1.8.0"
>>>Same error there.
>>>Last ditch effort, I'll let ntop try to find gdbm itself, but enable
debug
>anyway. ./configure --enable-debug
>>>I enable debug and it doesn't make any executable at all. I tell it
where
>gdbm is and it does not like it. I let it do everything by itself, and
it
>makes an executable, but that executable doesn't work. Do you know
what's
>going on?
>
>I'm afraid you're simply suspecting - and most likely incorrectly -
>something unfamiliar.���If you follow the instructions in
BUILD-NTOP.txt, it
>knows exactly where gdbm is.��And if ntop was having trouble with the
>database, you would see more messages (you do see the GDBM initialized
>message in your log, right?).
>
>Here's my log:
>
>Feb 19 21:12:13 tigger ntop: Wait please: ntop is coming up...
>Feb 19 21:12:13 tigger ntop: 19/Feb/2002 21:12:13 Initializing IP
>services...
>Feb 19 21:12:13 tigger ntop[22619]: Initializing GDBM...
>Feb 19 21:12:13 tigger ntop[22619]: Initializing network devices...
>Feb 19 21:12:13 tigger ntop[22619]: ntop v.2.0.1 CVS Feb 18 14:21 MT
(SSL)
>[i686-pc-linux-gnu] (02/18/02 03:14:17 PM build)
>Feb 19 21:12:13 tigger ntop[22619]: Listening on [eth0]
>Feb 19 21:12:13 tigger ntop[22619]: Copyright 1998-2002 by Luca Deri
><[EMAIL PROTECTED]>
>Feb 19 21:12:13 tigger ntop[22619]: Get the freshest ntop from
>http://www.ntop.org/
>Feb 19 21:12:13 tigger ntop[22619]: Initializing...
>Feb 19 21:12:13 tigger kernel: device eth0 entered promiscuous mode
>Feb 19 21:12:13 tigger ntop[22619]: Loading plugins (if any)...
>Feb 19 21:12:13 tigger ntop[22619]: Searching plugins in
>/usr/lib/ntop/plugins
>Feb 19 21:12:13 tigger ntop: SSL is present but https is disabled: use
-W
><https port> for enabling it
>Feb 19 21:12:13 tigger ntop: SSL is present but https is disabled: use
-W
><https port> for enabling it
>Feb 19 21:12:13 tigger ntop: 19/Feb/2002 21:12:13 Bye bye: I'm becoming
a
>daemon...
>Feb 19 21:12:13 tigger ntop: ntop startup succeeded
>
>Notice the "ntop v.2.0.1 CVS Feb 18 14:21" - that tells me what I'm
running
>
>What you don't say *anywhere* is which version of the source you
>downloaded... but it looks like you have ntop v.2.0.0
>
>1. If (as I suspect), it's the 2.0 release, try one of the later
snapshots -
>15Feb is one I've been recommending.��Get them from
>http://snapshot.ntop.org/��(wget
>http://snapshot.ntop.org/tgz/ntop-02-02-15.tgz)
>
>2. Run ntop under gdb and capture the output.��I've posted how to the
list
>before, I'll just cut & paste that into the FAQs (also at snapshot).
>
>When it bombs under gdb, grab the stuff I indicate and post that...
>
>-----Burton
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
>Of Rick Farina
>Sent: Thursday, February 21, 2002 11:41 PM
>To: [EMAIL PROTECTED]
>Subject: [Ntop-dev] ntop2.0
>
>
>First I'd like to say that I love this program, and it is truely amazing
>what it can do.��I had it working for about 2 weeks, and then for some
>reason it stopped.��Since then it will not work no matter what I do.��I
have
>completely logged EVERY step that I took to configure and build
everything
>even remotely related to ntop.��I think the problem lies somewhere with
my
>gdbm(1.8.0).��Please help me!
>A complete set of logs my config/make logs can be found at
>http://134.53.212.81/ntop
>I also give a little more information about my problem.
>If this message should have have gone to ntop-dev, then please forward
it to
>whoever it goes to, I just thought that it should go to this address.
>Thanks for all of the help, and thanks for the great program!
>
>Rick Farina
>Miami University
>Systems Analysis Major
>
>_______________________________________________
>Ntop-dev mailing list
>[EMAIL PROTECTED]
>http://listmanager.unipi.it/mailman/listinfo/ntop-dev
>
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop
