nsd users - May 2006 - Making accept() not block

NSD currently assumes that selecting on a TCP listen() socket will always
result in accept() not blocking.  However, it doesn't mark its TCP listen()
sockets as non-blocking, so there is probably a race condition at least on
some OSes with either the -N flag (number of servers to fork) set to 2 or
more, or if someone opens a connection and closes it by the time NSD tries
to accept().  This may result in NSD not answering any requests until it
receives its next TCP connection.

There is a simple fix to this, which is to just mark the listen() socket as
non-blocking.  An example patch against NSD 2.3.4 is attached below.  Or you
may download it from:

     https://www.die.net/tmp/5301574a642cbb78/nsd-2.3.4-nonblockingaccept.patch

                                     -- Aaron

---

diff -ur nsd-2.3.4/server.c nsd-2.3.4.safer/server.c
--- nsd-2.3.4/server.c	2006-04-06 07:26:35.000000000 -0700
+++ nsd-2.3.4.safer/server.c	2006-05-12 03:44:50.000000000 -0700
@@ -308,6 +308,11 @@
  		}
  #endif

+		if (fcntl(nsd->tcp[i].s, F_SETFL, O_NONBLOCK) == -1) {
+			log_msg(LOG_ERR, "fcntl failed: %s", strerror(errno));
+			return -1;
+		}
+
  		/* Bind it... */
  		if (bind(nsd->tcp[i].s, (struct sockaddr *)
nsd->tcp[i].addr->ai_addr, nsd->tcp[i].addr->ai_addrlen) != 0) {
  			log_msg(LOG_ERR, "can't bind the socket: %s",
strerror(errno));

Oh, I didn't notice it since my select()-reduction patch makes UDP sockets
non-blocking, but this race condition is present for UDP in NSD 2.3.4 as
well if -N is > 1.

The sequence would go something like:

1) Both processes select().

2) select() in both processes shows data to read on the same UDP socket, so
    both processes recvfrom().

3) recvfrom() in one socket gets the new packet, while the other process
    blocks until the next packet is available on that socket.

If you have more than one UDP socket open (multiple -a flags passed) and are
blocking on a socket that is very infrequently used, this could result in
all but one child process being unable to answer requests.  If you are on a
multi-processor machine, this would cause a significant reduction of NSD's
peak throughput on that machine.

The fix is straightforward: If you are going to be using select() or similar
for multiplexing, all network sockets you might pass to it need to be marked
as non-blocking.

                                     -- Aaron