From owner-freebsd-hackers Tue Apr 16 19:30:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA26776 for hackers-outgoing; Tue, 16 Apr 1996 19:30:43 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA26770 for ; Tue, 16 Apr 1996 19:30:38 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.7.5/8.7.3) with SMTP id WAA12073; Tue, 16 Apr 1996 22:29:17 -0400 (EDT) Message-Id: <199604170229.WAA12073@whizzo.transsys.com> X-Authentication-Warning: whizzo.transsys.com: Host localhost.transsys.com [127.0.0.1] didn't use HELO protocol To: "Karl Denninger, MCSNet" cc: hackers@freebsd.org From: "Louis A. Mamakos" Subject: Re: Silly socket question References: In-reply-to: Your message of "Tue, 16 Apr 1996 12:33:34 CDT." Date: Tue, 16 Apr 1996 22:29:17 -0400 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is there some option that can be passed to the stack to tell the system that > I don't *care* about any buffered metadata and that it needs to release the > socket resources *right now*? The parent process which accepted these > connections (but closed them) is still around, but the child (which > inherited them) is long gone. It sure smells like there is still an open fd associated with the connection. After you fork/exec the child process, the parent process should close the fd it accepted the connection on. A TCP connection in CLOSE_WAIT state means that it has recieved a FIN from the remote TCP (that is, the remote TCP did a close or shutdown, indicating it has no more data to send). The local TCP is in a state such that it can continue to send data to the remote host. This should only be the case if there's an open fd for the socket still around. Doing a close() on the fd in the parent will remove the last reference to the socket, and cause it to move from CLOSE_WAIT state to LAST_ACK and and finally CLOSED. It's likely that the remote TCP is sitting in FIN_WAIT_2 state since you've never sent it a FIN by closing the local socket. louie