Workaround patch for MS CLOSE_WAIT bug
Pierre A. Humblet
Sat Apr 27 06:33:00 GMT 2002
Pierre A. Humblet wrote in
>Weird behavior (details on request) can also be avoided by
>"closing on fork" the main sock after line (1) and deleting
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.
More information about the Cygwin-patches