Pierre A. Humblet wrote in http://cygwin.com/ml/cygwin-patches/2002-q2/msg00039.html
>Weird behavior (details on request) can also be avoided by >"closing on fork" the main sock after line (1) and deleting >line (2). This is an explanation for the record. Systems: Win98 & WinME Start a standalone sshd. From localhost or another machine launch 3 ssh sessions, in the order 1, 2, 3. Exit from #2 then from #1. #3 is then reset unexpectedly. Analysis: sshd has a daemon running and 3 forked workers. The workers have a duplicated listen socket, which they closed, and an active i/o socket. The daemon has an active listen socket. It doesn't matter if the 3 accepted sockets are closed or not in the daemon, so this problem is distinct from the MS CLOSE_WAIT bug. Fix (arrived at experimentally): do not duplicate the listen socket in the workers (they immediately close it anyway). It must be the case that cleaning up the duplicated sockets (improperly closed by MS) when the subprocesses exit out of order exposes another MS bug. It is serendipity that the "close on fork" approach developed for the CLOSE_WAIT bug also takes care of this one. The problem does not occur [more precisely, is hard to reproduce] when the workers are exec'ed (e.g. inetd) because the duplicated listen sockets exist only during the brief interval between the fork and the subsequent exec. The bug can be reproduced in other packages (e.g. qpopper) using forked workers. Pierre
