Workaround for ntop as daemon, is it ok?
Henner Morten Kruse
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
ro...@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 FLAGS REF OFFSET PRO NAME
48884 ntop cwd v d -------- - - -
/usr/ports/net/ntop/work/ntop-3.3.10
48884 ntop root v d -------- - - - /
48884 ntop 0 v c rw------ 12 421416 - /dev/pts/1
48884 ntop 1 v c rw------ 12 421416 - /dev/pts/1
48884 ntop 2 v c rw------ 12 421416 - /dev/pts/1
48884 ntop 3 v r rw-----l 1 12646 -
/var/db/ntop/prefsCache.db
48884 ntop 4 v r rw-----l 1 12557 -
/var/db/ntop/ntop_pw.db
48884 ntop 5 k - rw------ 1 0 - -
48884 ntop 6 v c rw------ 2 35673 - /dev/bpf
48884 ntop 7 s - rw---n-- 2 0 UDP 0.0.0.0:30903
0.0.0.0:0
48884 ntop 8 s - rw---n-- 2 0 UDP 0.0.0.0:56316
0.0.0.0:0
48884 ntop 9 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 1 8192 -
/var/db/ntop/LsWatch.db
And this is ntop running in background:
PID COMM FD T V FLAGS REF OFFSET PRO NAME
48842 ntop cwd v d -------- - - - /
48842 ntop root v d -------- - - - /
48842 ntop 0 v r r------- 1 24903680 -
/usr/local/etc/ntop/GeoLiteCity.dat
48842 ntop 1 v r r------- 1 1601536 -
/usr/local/etc/ntop/GeoIPASNum.dat
48842 ntop 2 v c rw------ 11 413845 - /dev/pts/1
48842 ntop 3 v r rw-----l 1 12646 -
/var/db/ntop/prefsCache.db
48842 ntop 4 v r rw-----l 1 12557 -
/var/db/ntop/ntop_pw.db
48842 ntop 5 s - rw------ 1 0 TCP 0.0.0.0:3000
0.0.0.0:0
48842 ntop 6 v c rw------ 2 32705 - /dev/bpf
48842 ntop 7 s - rw---n-- 1 0 UDP 0.0.0.0:48169
0.0.0.0:0
48842 ntop 8 s - rw---n-- 1 0 UDP 0.0.0.0:36849
0.0.0.0:0
48842 ntop 9 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 1 8192 -
/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(CONST_TRACE_INFO, "INIT: Bye bye: I'm becoming a daemon...");
detachFromTerminalUnderUnix(1);
} else { /* father */
traceEvent(CONST_TRACE_INFO, "INIT: Parent process is exiting (this is normal)");
exit(0);
}
}
myGlobals.mainThreadId = pthread_self();
traceEvent(CONST_TRACE_ALWAYSDISPLAY, "THREADMGMT[t%lu]: Now running as a daemon", myGlobals.mainThreadId);
#endif
}
/* **************************************** */
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:
PID COMM FD T V FLAGS REF OFFSET PRO NAME
54712 ntop cwd v d -------- - - - /
54712 ntop root v d -------- - - - /
54712 ntop 0 v r r------- 1 24903680 -
/usr/local/etc/ntop/GeoLiteCity.dat
54712 ntop 1 v r r------- 1 1601536 -
/usr/local/etc/ntop/GeoIPASNum.dat
54712 ntop 2 v c rw------ 11 884896 - /dev/pts/2
54712 ntop 3 v r rw-----l 1 12646 -
/var/db/ntop/prefsCache.db
54712 ntop 4 v r rw-----l 1 12557 -
/var/db/ntop/ntop_pw.db
54712 ntop 5 k - rw------ 1 0 - -
54712 ntop 6 v c rw------ 2 56988 - /dev/bpf
54712 ntop 7 s - rw---n-- 2 0 UDP 0.0.0.0:21649
0.0.0.0:0
54712 ntop 8 s - rw---n-- 2 0 UDP 0.0.0.0:15926
0.0.0.0:0
54712 ntop 9 s - rw---n-- 2 0 UDP 0.0.0.0:43003
0.0.0.0:0
54712 ntop 10 v r rw-----l 1 14612 -
/var/db/ntop/dnsCache.db
54712 ntop 11 v r rw-----l 1 322078 -
/var/db/ntop/macPrefix.db
54712 ntop 12 v r rw-----l 1 167936 -
/var/db/ntop/fingerprint.db
54712 ntop 13 s - rw------ 1 0 TCP 0.0.0.0:3000
0.0.0.0:0
54712 ntop 15 v r rw-----l 1 8192 -
/var/db/ntop/LsWatch.db
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?
Thanks in advance.
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
Jilles Tjoelker
> 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
> ro...@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