Situation is more and more complicated now.
First of all, I agree, the patch is too much "aggressive" for upcoming
3.0 release. Forget it for now, please.

Today, I make some other test - here is small recapitulation:

FreeBSD 5.2 has 2 different threading libraries now
 - KSE - kernel mode threads, its used when program is linked with -lkse
 - and old user mode threads, used when program is linked with -lc_r

The ntop works without any problem in daemon mode, when it's linked with KSE library,
but hangs when it's linked with c_r library. (Note, the hangs is not a right word - 
it's only major,
near infinite, slowdown in web interface). The ps show ntop in bpf state - I mean, its
not problem, because ps on FreeBSD shows state of first thread.

So, my original idea, broken fork(), is totally false.
Simply, im out of ideas now?

But, I still want to find real cause of this problem, and report it
 (to FreeBSD, to tcpdump workes, or here :)


Btw, the PR 51535 is repaired and closed

Michal Meloun


In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I'm going to strongly suggest we reject this change at the current stage.
> We have a lot of testing under our belts on the current arrangement and it
> works fine in all environments EXCEPT FreeBSD, which is known to be flakey
> re threads anyway.
>
> If you will maintain this as a FreeBSD - only patch, we can revisit it after
> 3.0...    Frankly I'd be more comfortable moving daemonize earlier, before
> the pcap_open_live - one of the post-3.0 things I'm looking at is a threads
> watchdog, which would be cleaner that way...
>
> Meanwhile, you should probably append this info the existing bug report on
> FreeBSD (http://www.freebsd.org/cgi/query-pr.cgi?pr=56339).  And also to the
> tcpdump workers list.  However, I'll bet you ultimately get the 'fork() and
> threads don't co-exist' answer.  Also, look at PR 51535 which is the other
> open problem in this area.
>
> Thanks!
>
> And cool findings.
>
> -----Burton
>
>
>
>

_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Reply via email to