It's working fine for me...
It sounds like you're deadlocked. What did I say the symptoms were?
"The symptom is that the web server is up, but no packets are being
processed, so the counts don't change. "
Check the source - the correct version has hash.c line 170:
if (((i+1) & MUTEX_FHS_MASK) == 0) {
not
if ((i+1) & MUTEX_FHS_MASK == 0) {
If you are running the new source, well, then, thats the OTHER deadlock.
I really doubt it's anything else - that graph is generated from a separate
set of data, it's not the rrd stuff and it's not by host, so it's not
subject to purge. It's drawn by void drawThptGraph(int sortedColumn) {} in
graph.c. It's reset in resetDevice() which is called when you reset the
stats via the web interface and in createDummyInterface() when you turn on
sflow and netflow. But that's it...
Check the info.html page and see if you're blocked and/or if the counters
are increasing and check the log for the self- message.
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Earl Terwilliger
Sent: Friday, December 13, 2002 2:36 PM
To: [EMAIL PROTECTED]
Subject: Re: [Ntop-dev] Deadlocks ... hanging ntop
Hello,
On the 5 minute mark...
I just downloaded the cvs after burton posted the fix and it all re-compiled
fine.
I notice that the "network load statistics" graph only shows data for 5
minutes. It changes every minute but only shows the last 5 minutes.... at
the
right of the graph.
????
Earl
On Friday 13 December 2002 15:20, Burton M. Strauss III wrote:
> There are a couple of reports (and both Luca and I have seen the problem
> across a range of OSes) with ntop deadlocking. The symptom is that the
web
> server is up, but no packets are being processed, so the counts don't
> change. It happens on the 5 minute mark, i.e. related to idle purge.
>
> Clearly, part of the problem was my performance change in hash.c for the
> idle purge of large networks. I've finally found the problem (operator
> precedence) and so I believe I've closed that problem. That fix is now in
> the cvs (if you track my stuff, it's refs 178 and 179). This code will be
> in the snapshot of 14Dec2002.
>
> It should be VASTLY better.
>
> However, I've still seen ntop deadlock with that fix in. Just much, MUCH
> less frequently.
>
>
> Over the past couple of days, I've put a couple of enhancements in to try
> and trap these things.
>
> 1) info.html (and textinfo.html) now report "blocked" mutexes.
>
> A single instance of a "blocked" mutex is NOT a problem (mutexes do block
> now and then).
>
> However, if it doesn't clear after a few seconds, that IS a problem. Best
> way to check is to refresh and see if the # of locks/unlocks grow.
>
>
> 2) Frees of unlocked mutexes are reported:
>
> WARNING: releaseMutex() call with an UN-LOCKED mutex [%s:%d]
>
>
> 3) self-LOCKING is reported:
>
> WARNING: accessMutex() call with a self-LOCKED mutex [from pbuf.c:1719
> processPacket, locked by processPacket]
>
> This is where a thread locks a mutex that it has already locked. Note
that
> this warning is imperfect - the fields ntop uses are added onto the POSIX
> Pthread mutex structure. There's no way to make the added code atomic w/o
> single threading ntop, so the simple minded wrapper I've put in place may
> give spurious results.
>
> It does not impact the functioning of ntop, it is just a log message.
>
> What I'm saying is, "DON'T PANIC".
>
> If ntop does deadlock (i.e. no packets being processed and the # of
> locks/unlocks doesn't grow), then the WARNING may explain why.
>
> But, if you see the warning and ntop doesn't deadlock, well, then it was
> just the way things got run.
>
> If you're running ntop capturing from more than one network card, it's
more
> likely to see a spurious message because there are two packet capture
> threads and (right now), the lock "keys" are the same. Adding the pid to
> the lock stuff would fix that, but the focus is on the deadlock, not the
> cosmetics. Especially if it's a busy network.
>
> If your ntop locks up and you have pulled hash.c revision 2.108 from the
> cvs (that is after
> 13Dec2002 18:50:48 in Pisa - 12:50:48pm US Central Time), please find the
> lines from the log and report them on ntop-dev.
>
>
> -----Burton
>
>
>
>
>
> _______________________________________________
> 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
