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
