"Normal" operating mode should have zero or a very small number of outstanding requests to resolve at any time.
You know, it could just be that what the code is really there to protect against happened - a huge influx of hosts to be resolved. Rather than have the queued database (gdbm file) grow for ever, ntop cuts off at 4K. I'd keep an eye on it to see if it happens again - and if so, check those counters - a port scan will cause a burst, possibly swamping the 4K limit, but will then gradually decline, as the resolution process works through them. I will fixup the msg so it's not as confusing. -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Kouprie, Robbert > Sent: Thursday, February 19, 2004 2:26 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [Ntop-dev] Cosmetic bug in address.c warning msg > > > The counters are increasing, so everything is ok :) > > -- Robbert > > Btw, the textinfo.html looks horrible in Opera. > > > -----Original Message----- > > From: Burton M. Strauss III [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 18, 2004 11:33 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [Ntop-dev] Cosmetic bug in address.c warning msg > > > > > > What shows up in textinfo.html? And is that thread getting/using cpu? > > > > That point is where DNSAR waits on the Semaphore for the next host to > > resolve, so just because it's in a wait state at 568 when you > > check it once > > doesn't mean it is nor is not locked up. > > > > Basically in queueAddress() one thread runs does this > > > > rc = gdbm_store(myGlobals.addressQueueFile, key_data, data_data, > > GDBM_INSERT); > > > > and then does this: > > > > incrementSem(&myGlobals.queueAddressSem); > > > > Which wakes up the other thread (DNSAR) which is here: > > > > waitSem(&myGlobals.queueAddressSem); > > > > does it's think and waits again... > > > > > > So if you're seeing hosts resolved, the textinfo.html > > counters should be > > incrementing. > > > > > > -----Burton > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf > > > Of Kouprie, Robbert > > > Sent: Wednesday, February 18, 2004 3:33 PM > > > To: 'Burton M. Strauss III ' > > > Cc: '[EMAIL PROTECTED]' > > > Subject: RE: [Ntop-dev] Cosmetic bug in address.c warning msg > > > > > > > > > Hi Burton, > > > > > > I agree on 1. Printing also the current# seems kinda > > pointless, as the > > > comparison is down only few lines before it. > > > > > > About 2. DNSAR is still running and it looks like it's > > working. It shows a > > > start msg in the logs, no stop msg and its thread (6 in my > > case - probably > > > because of Netflow or RRDplugin) is there. It shows this: > > > > > > (gdb) info stack > > > #0 0x00920c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > > > #1 0x001c9164 in [EMAIL PROTECTED] () from > > /lib/tls/libpthread.so.0 > > > #2 0x009755b8 in __JCR_LIST__ () from > > /usr/local/lib/libntop-3.0pre1.so > > > #3 0x00963d74 in waitSem (semId=0x97649c) at util.c:2058 > > > #4 0x0093e406 in dequeueAddress (notUsed=0x0) at address.c:568 > > > #5 0x001c47fc in start_thread () from /lib/tls/libpthread.so.0 > > > #6 0x002ffaba in clone () from /lib/tls/libc.so.6 > > > > > > Also, I actually don't see any visible degradation in ntop. > > After deleting > > > addressQueue.db and dnsCache.db and restarting ntop, I > > still see all hosts > > > getting resolved immediately. > > > > > > I do have other problems with 3.0pre1 (rrdPlugin running OOM fairly > > > quickly), but I'll report that seperately if I find time. > > > > > > Regards, > > > -- Robbert > > > > > > > > > -----Original Message----- > > > From: Burton M. Strauss III > > > To: [EMAIL PROTECTED] > > > Sent: 18-2-2004 16:18 > > > Subject: RE: [Ntop-dev] Cosmetic bug in address.c warning msg > > > > > > Sounds like a bunch of things... > > > > > > queueAddress() in address.c around 466ff > > > > > > 1. The counter gets incremented then the test occurs, so > > that's the 4097 > > > vs > > > 4096, cosmetics issue. Maybe just drop the current # from the (one > > > time) > > > message. > > > > > > 2. Sounds like the DNSAR thread has died. Either that, or > > you really > > > did > > > get flooded w/ dns requests. ntop can survive a DoS > > attack, but at some > > > point it just stops trying to resolve addreses until the > > flood stops. > > > > > > > > > > > > What do the stats in textinfo.html say?? > > > > > > Queued - dequeueAddress(): > > > > > > Total Queued.....398 > > > Not queued (duplicate).....0 > > > Maximum Queued.....9 > > > Current Queue.....0 > > > > > > > > > Resolved - resolveAddress(): > > > > > > Addresses to resolve.....398 > > > ....less 'Error: No cache database'.....0 > > > ....less 'Found in ntop cache'.....35 > > > Gives: # gethost (DNS lookup) calls.....363 > > > > > > > > > Check back in the log for the DNSAR thread start message, > > generated from > > > this in initialize.c: > > > > > > > > > /* > > > * Create the thread (6) - DNSAR - DNS Address > > Resolution - optional > > > */ > > > for(i=0; i<myGlobals.numDequeueThreads; i++) { > > > createThread(&myGlobals.dequeueAddressThreadId[i], > > dequeueAddress, > > > NULL); > > > traceEvent(CONST_TRACE_INFO, "THREADMGMT: Started > > thread (%ld) for > > > DNS > > > address resolution", > > > myGlobals.dequeueAddressThreadId[i]); > > > } > > > > > > > > > Feb 17 07:57:40 tigger ntop[13850]: THREADMGMT: Address resolution > > > thread > > > running... [MSGID8779240] > > > Feb 17 07:57:40 tigger ntop[13850]: THREADMGMT: Started thread > > > (1142135600) for DNS address resolution [MSGID0983766] > > > > > > So MSGID0983766 is from the parent and MSGID8779240 comes > > from the child > > > as > > > it starts up. Make sure there's no corresponding stop message: > > > > > > address.c 616: > > > > > > traceEvent(CONST_TRACE_WARNING, "THREADMGMT: Address > > resolution thread > > > terminated..."); > > > > > > That would be a bad thing. > > > > > > > > > Also, check and make sure the address res is still running. If you > > > connect > > > to the running ntop, > > > > > > (gdb) info threads > > > 8 Thread 1116957488 (LWP 13854) 0xffffe002 in ?? () > > > 7 Thread 1125350192 (LWP 13855) 0xffffe002 in ?? () > > > 6 Thread 1133742896 (LWP 13856) 0xffffe002 in ?? () > > > 5 Thread 1142135600 (LWP 13857) 0xffffe002 in ?? () > > > 4 Thread 1158921008 (LWP 13859) 0xffffe002 in ?? () > > > 3 Thread 1167313712 (LWP 13861) 0xffffe002 in ?? () > > > 2 Thread 1175706416 (LWP 13862) 0xffffe002 in ?? () > > > 1 Thread 1096315936 (LWP 13850) 0xffffe002 in ?? () > > > > > > It's typically #5 (assuming a single NIC): > > > > > > (gdb) thread 5 > > > [Switching to thread 5 (Thread 1142135600 (LWP 13857))]#0 > > 0xffffe002 in > > > ?? > > > () > > > (gdb) info stack > > > #0 0xffffe002 in ?? () > > > #1 0x400ba5ed in dequeueAddress (notUsed=0x0) at address.c:568 > > > #2 0x41283484 in start_thread () from /lib/tls/libpthread.so.0 > > > (gdb) > > > > > > > > > -----Burton > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Behalf > > > > Of Kouprie, Robbert > > > > Sent: Wednesday, February 18, 2004 8:34 AM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: [Ntop-dev] Cosmetic bug in address.c warning msg > > > > > > > > > > > > Feb 18 14:33:02 ntop ntop[3060]: [address:485] > > **WARNING** Address > > > > resolution queue is full [4097 of 4096 slots] > > > > Feb 18 14:33:02 ntop ntop[3060]: [address:487] Addresses in > > > > excess won't be > > > > resolved > > > > > > > > ? ;) > > > > > > > > -- Robbert > > > > > > > > > > > > _______________________________________________ > > > > Ntop-dev mailing list > > > > [EMAIL PROTECTED] > > > > http://listgateway.unipi.it/mailman/listinfo/ntop-dev > > > > > > > > > > _______________________________________________ > > > Ntop-dev mailing list > > > [EMAIL PROTECTED] > > > http://listgateway.unipi.it/mailman/listinfo/ntop-dev > > > > > > > > > _______________________________________________ > > > Ntop-dev mailing list > > > [EMAIL PROTECTED] > > > http://listgateway.unipi.it/mailman/listinfo/ntop-dev > > > > > > > _______________________________________________ > > Ntop-dev mailing list > > [EMAIL PROTECTED] > > http://listgateway.unipi.it/mailman/listinfo/ntop-dev > > > > > _______________________________________________ > Ntop-dev mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop-dev > _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
