Cool beans ... I'll commit it...
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Terrence Martin
Sent: Sunday, February 27, 2005 2:48 PM
To: [email protected]
Subject: Re: [Ntop] ntop will not capture packets when options used
Yes that is correct.
Terrence
Burton Strauss wrote:
>So you ended up with this?
>
>$ cat LINUXwhitebox3.0
>
>#!/bin/sh
>
>echo " Setting Whitebox Linux 3.0 specific flag values"
>
># If we have krb5.h and openssl was compiled with it, we need the -I
>setting # since there's no way to easily test the latter and no harm
>from an extra -I, # just do it...
>if test -d /usr/kerberos/include &&
> test -f /usr/kerberos/include/krb5.h; then
> CPPFLAGS="-I/usr/kerberos/include/ ${CPPFLAGS}"
>fi
>
>CPPFLAGS="${CPPFLAGS} -DFORPRENPTL"
>$
>
>If so, that's easy to add...
>
>-----Burton
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Terrence Martin
>Sent: Friday, February 25, 2005 10:11 PM
>To: [email protected]
>Subject: Re: [Ntop] ntop will not capture packets when options used
>
>It works! :) Well ntop -d -L -u ntop does, and before it did not.
>
>Here is what I did based on your replies.
>
>I am running Whitebox Enterprise Linux so I had to create a file
>LINUXwhitebox3.0 in configureextra once I figured out how that worked
>and how the configure was guessing at my system. The file is an exact
>copy of
>LINUXredhat3 (since whitebox is RHEL3 recompiled with Redhat trademarks
>removed) with the following line added at the end.
>
>CPPFLAGS="${CPPFLAGS} -DFORPRENPTL"
>
>I then recompiled and re-installed. Everything seems to be working fine
>now when I run
>
>ntop -d -L -u ntop
>
>That is ntop captures packets on interfaces just like when I did not
>use syslog previously without the above change.
>
>Thanks for all your help Burton and please feel free to propegate this
>change if you want.
>
>Cheers,
>
>Terrence
>
>Burton Strauss wrote:
>
>
>
>>It could be as simple as RHEL's glibc not being compiled w/
>>_REENTRANT, so the routines aren't thread-safe. If that's what it is,
>>then the RH8 fix will solve it by moving the serialization into ntop.
>>
>>It could be other things in glibc (which exposes a whole raft of
>>issues, not just NPTL).
>>
>>
>>Remember, RH9 is the red-headed unwed step child. It's the first
>>major distro/release that included NPTL and glib 2.3.x (IIRC), etc.
>>
>>* Lots of packages had problems and crafted work-arounds (and/or
>>cleaned up their code).
>>* Lots of changes happened in glibc, NPTL, gcc, etc. too.
>>
>>It's not that linux threads was 'wrong', but that it was an older,
>>partial, interpretation of the POSIX standard that didn't hold up well
>>to 1000s of threads. However, the -isms from linuxthreads permeated a
>>lot of software, ntop included. Some software didn't care - simple
>>synchronization works the same in both linuxthreads and NPTL - it's
>>only
>>
>>
>the edge cases that changed.
>
>
>>We did a lot of work post RH9 to cleanup ntop's thread handling (also
>>because of issues exposed by FreeBSD's userland threads - another,
>>'valid but different' interpretation of the POSIX standard). However,
>>we've also continued to shrink the mutex lock spans and identify
>>additional lock requirements 3.0 and 3.1, so there may be edge cases
>>now exposed that we didn't see before.
>>
>>
>>-----Burton
>>
>>
>>
>>-----Original Message-----
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
>>Of Terrence Martin
>>Sent: Friday, February 25, 2005 12:01 PM
>>To: [email protected]
>>Subject: Re: [Ntop] ntop will not capture packets when options used
>>
>>I will have a look at it again. The thing is I am actually running an
>>nptl version of RH, specifically RHEL where RedHat has retroactively
>>placed nptl threads into a 2.4 kernel.
>>
>>Presumable -d does something with syslog as well and hence why it
>>triggers the log hang if that is what is occuring.
>>
>>I will try the RH8.0 fix you outline below and see if the behaviour
>>
>>
>changes.
>
>
>>I am suprised that this has not come up more often, aside from that
>>one post I saw earlier in Feb. that showed the problem with RH9 (very
>>similar to RHEL3).
>>
>>Thanks for the help, I will followup with what I find out.
>>
>>Terrence
>>
>>
>>
>>Burton Strauss wrote:
>>
>>
>>
>>
>>
>>>Sounds like the syslog() serialization problem that Eric indicated I
>>>had fixed in the cvs. -t 4 or higher may expose the problem more
>>>often because it's logging more messages and thus is likely to have
>>>noise
>>>
>>>
>>>
>>>
>>>from multiple threads simultaneously.
>>
>>
>>
>>
>>>Here's the cvs log message:
>>>
>>>revision 2.293
>>>date: 2005-01-28 15:56:41 +0000; author: burton; state: Exp; lines:
>>>+9 -0 "Fix" for the 'RedHat 8 hangs' problem.
>>>
>>>In my testing for this problem, I have seen all of ntop's threads
>>>hanging in the syslog() routines.
>>>
>>>This "fix" adds a mutex around the calls. It fixes the problem for
>>>me, at a cost of some slight single threading. Since the problem
>>>shows up most often at startup when a bunch of threads are issuing
>>>their initial messages, that's not a big hit. Still, I can't PROVE
>>>it's the fix, so it's conditional on a -D defined item
>>>
>>>
>(configureextra/LINUXredhat8.0:
>
>
>>> CPPFLAGS="${CPPFLAGS} -DFORPRENPTL"
>>>
>>>)
>>>
>>>Here's where it gets odd...
>>>
>>>If you skulk around the web, you'll see a lot of threads that talk
>>>about random hangs in syslog() routines, across lots of different
>>>open source projects.
>>>It appears that syslog() routines aren't thread safe... and the usual
>>>'answer'
>>>is to create some sort of thread-safe wrapper. That's what I've done
>>>
>>>
>here.
>
>
>>>Yet, strangely, I've never seen this w/ ntop before 3.1.
>>>
>>>If this is really the problem, then other pre-NPTL Linuxes could also
>>>have the same hang. If so, we will need to adjust their
>>>configureextra/LINUXxxxx routines like the change this fix makes in
>>>
>>>
>>>
>>>
>>configureextra/LINUX/redhat8.0!
>>
>>
>>
>>
>>>-----Burton (ref 541)
>>>
>>>
>>>As it indicates you may also need to enable the FORPRENPTL #define to
>>>enable the 'fix'. Since I only knew RH7.x and 8 had the problem,
>>>those are the only configureextra entries I adjusted. Figure out
>>>which one you are using and add the line from LINUXredhat8.0 to it.
>>>Give
>>>
>>>
>that a try.
>
>
>>>
>>>-----Burton
>>>
>>>-----Original Message-----
>>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
>>>Of Terrence Martin
>>>Sent: Friday, February 25, 2005 1:15 AM
>>>To: [email protected]
>>>Subject: Re: [Ntop] ntop will not capture packets when options used
>>>
>>>Ok I built and installed the cvs version.
>>>
>>>I have not confirmed the two of the troublesome switches are -d and -L.
>>>That is if I use -d or -L alone, or together the web interface runs,
>>>but does not want to capture packets. This is true for the long
>>>versions of these options.
>>>
>>>However I can use options like -i eth0,eth1 or -u ntop
>>>
>>>eg
>>>ntop -i eth0,eth1 -u ntop
>>>
>>>Now here is something interesting. When I use the -t 5 option for
>>>more logging the web interface does not come up at all with -d and/or -L.
>>>However it still works fine without those options.
>>>
>>>Does anyone know what -d and/or -L does that creates such different
>>>behaviour?
>>>
>>>Terrence
>>>
>>>
>>>[EMAIL PROTECTED] wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>That sounds like a problem I was having but on RH7.3 (I think it was).
>>>>When I had the problem it was when I used it in daemon mode (-d).
>>>>Try it without the -d and see if it solves the problem. If so, I
>>>>think Burton patched it in the current development version. Try a
>>>>CVS fetch and build it your self to see if it goes away.
>>>>
>>>>Directions for CVS here: http://www.ntop.org/download.html
>>>>
>>>>You may have to add the word "export" to your CVSROOT command like so:
>>>>
>>>>export CVSROOT=:pserver:[EMAIL PROTECTED]:/export/home/ntop
>>>>
>>>>--
>>>>
>>>>J. Eric Josephson
>>>>Director of Network and System Operations
>>>>978-720-2159
>>>>mailto:[EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> Terrence Martin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> <[EMAIL PROTECTED] To: [email protected]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> ucsd.edu> cc:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> Sent by: Subject: [Ntop] ntop will
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>not capture packets when options used
>>>
>>>
>>>
>>>
>>>
>>>
>>>> [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> i.it
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> 02/24/2005 02:40
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> PM
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> Please respond to
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> ntop
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I am running ntop 3.1 on a RHEL3 (Whitebox) system.
>>>>I have installed using pre-compiled binaries from Dag Wiers site, as
>>>>well as rebuilding the RPM myself and installing that. I have not
>>>>tried the tar ball.
>>>>Kernel 2.4.21-15.0.3.EL
>>>>The underlying hardware is a Via EPIA M6000 with a added tulip based
>>>>ethernet card
>>>>
>>>>The problem I am having is that ntop only seems to properly capture
>>>>packets if I do not give it any command line options.
>>>>
>>>>If I run ntop plain as root it starts up and listens to the default
>>>>port 3000. I connect and get graphs for all the current data. If I
>>>>run ntop with a switch the interface still comes up but the
>>>>interface reports no packets captured.
>>>>
>>>>eg. ntop -d or ntop -d -L or using /etc/ntop.conf
>>>>
>>>>Does anyone know what might be causing this issue?
>>>>
>>>>The other thing I noticed is that when I hit crtl-c to stop the
>>>>plain command line ntop I often got a segfault when it closed. Not
>>>>sure if that is normal.
>>>>
>>>>Also is there an archive for this list?
>>>>
>>>>Thanks for any suggestions,
>>>>
>>>>Terrence
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>Ntop mailing list
>>>>[email protected]
>>>>http://listgateway.unipi.it/mailman/listinfo/ntop
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>Ntop mailing list
>>>>[email protected]
>>>>http://listgateway.unipi.it/mailman/listinfo/ntop
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>Ntop mailing list
>>>[email protected]
>>>http://listgateway.unipi.it/mailman/listinfo/ntop
>>>
>>>_______________________________________________
>>>Ntop mailing list
>>>[email protected]
>>>http://listgateway.unipi.it/mailman/listinfo/ntop
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>Ntop mailing list
>>[email protected]
>>http://listgateway.unipi.it/mailman/listinfo/ntop
>>
>>_______________________________________________
>>Ntop mailing list
>>[email protected]
>>http://listgateway.unipi.it/mailman/listinfo/ntop
>>
>>
>>
>>
>>
>
>_______________________________________________
>Ntop mailing list
>[email protected]
>http://listgateway.unipi.it/mailman/listinfo/ntop
>
>_______________________________________________
>Ntop mailing list
>[email protected]
>http://listgateway.unipi.it/mailman/listinfo/ntop
>
>
>
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
