Nope... Here's the scenario - you are running along for days w/o problems
and hit a deadlock.  If the extra info is available, I have a prayer (kill
-SIGHUP) of catching a sniff of what happened.  If it's not there, no
prayer.

-----Burton 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arn
Vollebregt
Sent: Tuesday, January 24, 2006 8:39 AM
To: [email protected]
Subject: Re: [Ntop] queuePacket/dequeuePacket errors

From: "Burton Strauss" <[EMAIL PROTECTED]>
> In all the time I've traced the code - and I've literally spent months 
> on this on and off - there is nothing that would cause any data loss.

That is good to know, this was my main concern.

> AFAIK, --disable-mutexextrainfo is perfectly safe.  That's why I put 
> it in there...

Works like a charm.
Perhaps you could consider this mutex logging an opt-in setting instead of
opt-out? When you get these warnings and dont know all this background it
tends to freak you out ;) And since there is no harm done...

> I've posted diatribes on this before - look in ntop-dev if you want 
> more of the gore.

No offense, but I just want to use the program and not know all the details
about the inner working. So no thank you :)

Thx again for the help,

Arn Vollebregt

--
"Wisdom lies not in obtaining knowledge, but in using it in the right way"
 - kroesjnov

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
> Of Arn Vollebregt
> Sent: Tuesday, January 24, 2006 4:44 AM
> To: [email protected]
> Subject: Re: [Ntop] queuePacket/dequeuePacket errors
>
> From: "Burton Strauss" <[EMAIL PROTECTED]>
>> You can use Gmane or Google to search the archives
>
> Ah, didnt know Gmane yet, usefull service.
> Not finding it via google was my own fault, my search query was to 
> specific.
>
>> both are documented in docs/FAQ.
>
> Ok, I have now found your FAQ when noticing your email address. 
> Perhaps you can convince the maintained of ntop.org to refer to your 
> updated FAQ?
> Might
> safe some emails on the mailinglist ;)
>
>> Read the stuff in the archives and docs/FAQ on self-LOCKED - it will 
>> give you a basis for the discussion.
>
> Okay, that gave me some idea on what these warnings are about. For now 
> I added --disable-mutexextrainfo to my ntop.conf for I cant find yet 
> on how to force ntop to a single CPU yet. That seems like a shame 
> anyway, having 2 dual core CPU's and restricting ntop (one of the most 
> resource hungy processes on the system) to a single CPU.
> I am still experiencing the slow web-interface at times, I guess it's 
> 'collides' with a hash flush or some other update from ntop, trying a 
> couple of seconds later it loads okay again.
>
> Thank you for your patience and time, and I'd like to say you did 
> quite a nice job on the FAQ.
>
> Arn Vollebregt
>
> --
> "Wisdom lies not in obtaining knowledge, but in using it in the right way"
> - kroesjnov
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
>> Of Arn Vollebregt
>> Sent: Saturday, January 21, 2006 11:48 AM
>> To: [email protected]
>> Subject: Re: [Ntop] queuePacket/dequeuePacket errors
>>
>> From: "Burton Strauss" <[EMAIL PROTECTED]>
>>> Read the back traffic on ntop - it's a multiple threaded app.
>>
>> My bad, didnt know this.
>> On reading back; I just joined the list, and the webarchives dont 
>> provide a search function, so 'reading back' isnt very feasable imho.
>>
>>> Self-locked really shouldn't happen in 3.2, although it's just a 
>>> warning -
>>
>> Well, apparently it does happen :)
>> What does this self-locked actually mean for me? Will I loose the 
>> data concerned? Will it be queued?
>> And more important; Are there any pointers on what is causing these 
>> errors?
>>
>>> usually the data at risk is only the locking data itself.
>>
>> If it would occur a couple of times a day I would not be very 
>> concerned, but my logs are really filling up with these errors. I 
>> guess there is a decent amount of data at risk
>>
>>> As a test, you can try using
>>> the OS to restrict ntop to one processor (if it will allow you to do 
>>> so).
>>
>> I'll look into this on monday when I have access to the server again.
>>
>> NTOP is also having peaks of 90% CPU load, this also doesnt seem very 
>> normal to me?
>> tia for your time.
>>
>> Arn Vollebregt
>>
>> --
>> "Wisdom lies not in obtaining knowledge, but in using it in the right 
>> way"
>> - kroesjnov
>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
>>> Of Arn Vollebregt
>>> Sent: Friday, January 20, 2006 4:24 AM
>>> To: [email protected]
>>> Subject: [Ntop] queuePacket/dequeuePacket errors
>>>
>>> Hello,
>>>
>>> I am having some troubles with running NTOP on a 100Mbit network 
>>> with quite some traffic to monitor. A short while after starting up 
>>> the process the webinterface becomes sluggisch and unresponsive at
times.
>>> When I check /var/log/messages I am seeing a flood of the errors 
>>> below repeating
>>>
>>> **WARNING** tryLockMutex() called 'queuePacket' with a self-LOCKED 
>>> mutex [EMAIL PROTECTED]:2219]
>>> **WARNING** accessMutex() called 'dequeuePacket' with a self-LOCKED 
>>> mutex [EMAIL PROTECTED]:2399]
>>>
>>> NTOP is also spawning multiple processes, at the time of writing I 
>>> am up to
>>> 9 NTOP processes, running for a small 5 minutes now.
>>>
>>> I recon NTOP cannot keep up with the traffic or the amount of hosts 
>>> and their data, are there ways to tweak NTOP? I figure the machine 
>>> itself is not the problem, since it concerns a dual Xeon 2.4Ghz, 
>>> 1Gig of RAM with a SCSI harddisk.
>>>
>>> Arn Vollebregt
>>>
>>> --
>>> "Wisdom lies not in obtaining knowledge, but in using it in the 
>>> right way"
>>> - kroesjnov
>>>
>>> _______________________________________________
>>> Ntop mailing list
>>> [email protected]
>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>>
>>> _______________________________________________
>>> Ntop mailing list
>>> [email protected]
>>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date:
>>> 19-1-2006
>>>
>>
>> _______________________________________________
>> Ntop mailing list
>> [email protected]
>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>
>> _______________________________________________
>> Ntop mailing list
>> [email protected]
>> http://listgateway.unipi.it/mailman/listinfo/ntop
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
>> 20-1-2006
>>
>
> _______________________________________________
> Ntop mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop
>
> _______________________________________________
> Ntop mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date: 
> 20-1-2006
> 

_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to