Further investigation shows that this symptom is caused by a service that does not read(2) from the file descriptor provided by inetd, and that the packet received was not empty. The man page does not say this is bad.
In the test case, "netstat -an | grep 9988" showed a receive queue that never grew any shorter. As a result, the inetd select(2) would continue to show data available, even for one packet. Adding a read(2) to the service fixes it. The service wasn't intended to receive data, yet data was sent. There is no practical way that inetd can handle this situation ... it cannot know that a service program will not read the socket. The current behaviour is to respawn the service until the maximum number of server instances is reached, then loop for 60 seconds and try again. The attached patch adds this to the BUGS section of the man page, since it was not clear from the nowait/wait section. -- James Cameron http://ftp.hp.com.au/sigs/jc/
--- openbsd-inetd-0.20050402/inetd.8 2007-08-13 11:41:48.000000000 +1000 +++ openbsd-inetd-0.20050402-436803/inetd.8 2007-08-13 11:40:54.000000000 +1000 @@ -474,3 +474,11 @@ .Dq rpc on IPv6 is not tested enough. Kerberos support on IPv6 is not tested. +.Pp +Server programs used with +.Dq dgram +.Dq udp +.Dq nowait +must read from the network socket, or +.Nm inetd +will spawn processes until the maximum is reached.
