Re: Workaround for ntop as daemon, is it ok?
On Fri, Nov 27, 2009 at 09:19:11AM +0100, Henner Morten Kruse wrote: > I have just set up an ntop server based on 8.0-RELEASE. > FreeBSD ntop 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 > r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > After installing ntop 1.3.10 and all dependencies from the ports ntop > did work, but when running ntop as a daemon I got permanent and repeating > warning messages: > [warn] kevent: Bad file descriptor > [...] > I found out that ntop forks another thread for the daemon and kills the > initial one. The problem with this behaviour is that the kqueue is > started by the initial thread and the daemon thread doesn't use the > same file descriptors. So the kqueue is lost. That's a process, not a thread. > [...] > When I change the fork() in line 186 to rfork(RFPROC) everything works > and I get no more warning messages and procstat reports an existing > kqueue for the daemonized ntop: > So my question to this is: > Is my workaround ok or could this cause any problems? And what is the cause > of these warnings? Is it a bug or incapability in the kqueue implementation > or is it caused by bad code in ntop? Because it refers to other file descriptors, a kqueue is only really meaningful in the file descriptor table it was created in (this could be avoided for events that do not refer to file descriptors, and I think Solaris's "ports" system does that). As described in the kqueue(2) man page, calling rfork(2) without RFFDG will allow sharing the kqueue between the two processes. As long as the parent process exits quickly, or no "tricks" with file descriptor numbers are done, this is pretty safe. Another fix is to create the kqueue in the child process. -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Workaround for ntop as daemon, is it ok?
Hi,
I have just set up an ntop server based on 8.0-RELEASE.
FreeBSD ntop 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
After installing ntop 1.3.10 and all dependencies from the ports ntop
did work, but when running ntop as a daemon I got permanent and repeating
warning messages:
[warn] kevent: Bad file descriptor
ktrace reported the following:
47944 100098 initial thread CALL kevent(0x5,0x29ed8700,0x1,0x29ed8c00,
0x40,0)
47944 100098 initial thread RET kevent 1
47945 100139 ntop CALL kevent(0x5,0x29ed8700,0x3,0x29ed8c00,0x40,
0xbfbfd8a4)
47945 100139 ntop RET kevent -1 errno 9 Bad file descriptor
"[warn] kevent: Bad file descriptor
I found out that ntop forks another thread for the daemon and kills the
initial one. The problem with this behaviour is that the kqueue is
started by the initial thread and the daemon thread doesn't use the
same file descriptors. So the kqueue is lost.
This is ntop running in foreground (note fd 5, this is the kqueue):
PID COMM FD T V FLAGSREF OFFSET PRO NAME
48884 ntop cwd v d - - -
/usr/ports/net/ntop/work/ntop-3.3.10
48884 ntop root v d - - - /
48884 ntop0 v c rw-- 12 421416 - /dev/pts/1
48884 ntop1 v c rw-- 12 421416 - /dev/pts/1
48884 ntop2 v c rw-- 12 421416 - /dev/pts/1
48884 ntop3 v r rw-l 1 12646 -
/var/db/ntop/prefsCache.db
48884 ntop4 v r rw-l 1 12557 -
/var/db/ntop/ntop_pw.db
48884 ntop5 k - rw-- 1 0 - -
48884 ntop6 v c rw-- 2 35673 - /dev/bpf
48884 ntop7 s - rw---n-- 2 0 UDP 0.0.0.0:30903
0.0.0.0:0
48884 ntop8 s - rw---n-- 2 0 UDP 0.0.0.0:56316
0.0.0.0:0
48884 ntop9 s - rw---n-- 2 0 UDP 0.0.0.0:56311
0.0.0.0:0
48884 ntop 10 v r rw-l 1 13782 -
/var/db/ntop/dnsCache.db
48884 ntop 11 v r rw-l 1 652448 -
/var/db/ntop/macPrefix.db
48884 ntop 12 v r rw-l 1 167936 -
/var/db/ntop/fingerprint.db
48884 ntop 13 v r r--- 1 24903680 -
/usr/local/etc/ntop/GeoLiteCity.dat
48884 ntop 14 v r r--- 1 1601536 -
/usr/local/etc/ntop/GeoIPASNum.dat
48884 ntop 15 s - rw-- 1 0 TCP 0.0.0.0:3000
0.0.0.0:0
48884 ntop 17 v r rw-l 18192 -
/var/db/ntop/LsWatch.db
And this is ntop running in background:
PID COMM FD T V FLAGSREF OFFSET PRO NAME
48842 ntop cwd v d - - - /
48842 ntop root v d - - - /
48842 ntop0 v r r--- 1 24903680 -
/usr/local/etc/ntop/GeoLiteCity.dat
48842 ntop1 v r r--- 1 1601536 -
/usr/local/etc/ntop/GeoIPASNum.dat
48842 ntop2 v c rw-- 11 413845 - /dev/pts/1
48842 ntop3 v r rw-l 1 12646 -
/var/db/ntop/prefsCache.db
48842 ntop4 v r rw-l 1 12557 -
/var/db/ntop/ntop_pw.db
48842 ntop5 s - rw-- 1 0 TCP 0.0.0.0:3000
0.0.0.0:0
48842 ntop6 v c rw-- 2 32705 - /dev/bpf
48842 ntop7 s - rw---n-- 1 0 UDP 0.0.0.0:48169
0.0.0.0:0
48842 ntop8 s - rw---n-- 1 0 UDP 0.0.0.0:36849
0.0.0.0:0
48842 ntop9 s - rw---n-- 1 0 UDP 0.0.0.0:64119
0.0.0.0:0
48842 ntop 10 v r rw-l 1 13284 -
/var/db/ntop/dnsCache.db
48842 ntop 11 v r rw-l 1 499464 -
/var/db/ntop/macPrefix.db
48842 ntop 12 v r rw-l 1 167936 -
/var/db/ntop/fingerprint.db
48842 ntop 14 v r rw-l 18192 -
/var/db/ntop/LsWatch.db
After further investiagations I found the function which is responsible
for the fork at line 172 of ntop.c.
/* */
void daemonizeUnderUnix(void) {
#ifndef WIN32
int childpid;
signal(SIGHUP, SIG_IGN);
#ifdef HANDLE_DIED_CHILD
signal(SIGCHLD, handleDiedChild);
#else
signal(SIGCHLD, SIG_IGN);
#endif
signal(SIGQUIT, SIG_IGN);
if((childpid=fork()) < 0)
traceEvent(CONST_TRACE_ERROR, "INIT: Occurred while daemonizing
(errno=%d)", errno);
else {
#ifdef DEBUG
traceEvent(CONST_TRACE_INFO, "DEBUG: after fork() in %s (%d)",
childpid ? "parent" : "child", childpid);
#endif
if(!childpid) { /* child */
traceEvent(CO
Ntop 3.0 and Shared Library Problem
Hey Im running FreeBSD 4.9, and ive installed ntop-3.0 from Ports. Now ive had issues with this before, so i decided to remove any and all old packages, and all duplicate packages, and all dependencies that ntop has that were out of date. I then reconfigured and re-built and installed ntop from scratch. I fixed all the config errors that appeared and all options i wanted. And i built and installed ntop with both dynaic plugins enabled and --enable-static-plugin option. I have also checked that all the permissions for all the plugins and directories and everything was correct. But no matter what i do, i still get this problem. Sat Jun 19 15:55:45 2004 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function [Invalid shared object handle 0x28070900] Sat Jun 19 15:55:45 2004 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/nfsPlugin.so' entry function [Invalid shared object handle 0x28070c00] Sat Jun 19 15:55:45 2004 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid shared object handle 0x28070f00] Sat Jun 19 15:55:45 2004 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function [Invalid shared object handle 0x29b90200] The odd and strange thing is, i have a few other FreeBSD 4.9 Servers, where ntop compiles and installs the same as above, with no extra things needed to be done, and no other configure options passed, and ntop compiles and runs perfectly without a single one of the errors above. Some of the other freebsd servers where ntop works fine, is the exact same hardware as the one above where it doesnt work. If anyone has any ideas or any suggestions, i am willing to try anything. Any help will be appreciated. Thanks /Cole ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ntop, worlds greatest network monitor, no go on FreeBSD (fwd)
-- Forwarded message -- Date: Thu, 16 Nov 2000 17:20:11 -0800 (PST) From: FengYue <[EMAIL PROTECTED]> To: Stanley Hopcroft <[EMAIL PROTECTED]> Subject: Re: ntop, worlds greatest network monitor, no go on FreeBSD you may consider copying this message to [EMAIL PROTECTED] On Thu, 16 Nov 2000, Stanley Hopcroft wrote: ->Dear Ladies and Gentlemen, -> ->I am writing to ask for someone to provide advice to the ntop project ->(http://www.ntop.org) on porting to FreeBSD. -> ->There are a number of problems with ntop (1.3.2 26th October) on ->FreeBSD (eg Mr Petri's letter of a few weeks ago) among them that when ->it's built with pthread support (-pthread), it uses all of the CPU ->(built without pthread support, it behaves). -> ->The problems are manifested on FreeBSD 4.x. -> ->ntop is able to use threads on many other platforms. -> ->ntop is a wonderful monitor. If you have ever wanted RMON2 like ability ->in software with a browser interface, ntop is for you. -> ->There is a port of ntop (for 1.1) but it displays the same CPU hogging ->behaviour as the later version. -> ->There has been no response from the ntop FreeBSD port mailing list. -> ->Thank you. -> ->Yours sincerely, -> -> ->S Hopcroft -> ->Network Specialist ->IP Australia -> ->+61 2 6283 3189 ->+61 2 6281 1353 FAX -> -> -> ->To Unsubscribe: send mail to [EMAIL PROTECTED] ->with "unsubscribe freebsd-isp" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ntop
(This is pobably inapproprate for -hackers. Reply to me alone or move it to -questions, I guess) On Mon, Feb 07, 2000 at 01:29:33PM +0100, Christoph Kukulies wrote: [ntop] > While building it I found that configure said: > > ... > > checking whether time.h and sys/time.h may both be included... yes > checking for lsof... no > > WARNING: unable to locate lsof. Some ntop features will be disabled. > > checking for main in -lncurses... yes > ... > > Well, always assuming FreeBSD being one of the most fully fledged > OSs WRT networking, I'm wondering what sort of feature I'm missing > here. /usr/ports/sysutils/lsof -- Mike Bristow, Geek At Large ``Beware of Invisible Cows'' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: ntop
Look at /usr/ports/sysutils/lsof To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ntop
I've been advised by someone to try to use 'ntop', an network analysis tool. Found it in the FreeBSD ports collection. While building it I found that configure said: ... checking whether time.h and sys/time.h may both be included... yes checking for lsof... no WARNING: unable to locate lsof. Some ntop features will be disabled. checking for main in -lncurses... yes ... Well, always assuming FreeBSD being one of the most fully fledged OSs WRT networking, I'm wondering what sort of feature I'm missing here. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
