Re: Workaround for ntop as daemon, is it ok?

2009-11-27 Thread Jilles Tjoelker
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?

2009-11-27 Thread Henner Morten Kruse
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(CONST_TRACE_INFO, "INIT: Bye bye: I'm becoming a daemon...")