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
