Workaround for ntop as daemon, is it ok?

Jilles Tjoelker jilles at stack.nl
Fri Nov 27 17:08:28 UTC 2009


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
>  root at 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


More information about the freebsd-hackers mailing list