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
