From: "Lewis G Rosenthal" Received: from [50.73.8.217] (account lgrosenthal@2rosenthals.com HELO [192.168.200.28]) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTPSA id 13730495 for ecs-isp@2rosenthals.com; Wed, 30 Jul 2025 11:54:16 -0400 Subject: Re: [eCS-ISP] socket - no buffer space availble To: eCS ISP Mailing List References: Organization: Rosenthal & Rosenthal, LLC Message-ID: <688A4028.7020506@2rosenthals.com> Date: Wed, 30 Jul 2025 11:54:16 -0400 User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi... On 07/29/25 07:25 pm, Steven Levine wrote: > In , on 07/29/25 > at 07:45 PM, "Massimo S." said: > > Hi Massimo, > >>> 0 STREAM 42164 http..80 217.182.195.225 FIN_WAIT_2 >>> 0 STREAM 56842 https..443 103.42.4.140 FIN_WAIT_2 >>> 0 STREAM 18331 http..80 51.68.111.239 FIN_WAIT_2 >>> 0 STREAM 62505 http..80 91.225.160.193 FIN_WAIT_2 >> FIN_WAIT_2 has no universally mandated timeout in TCP protocol, so some >> OSes keep these sockets indefinitely without cleanup. > This may have been true at one time. However, all the examples I'm seem > imply that the current default timeout is 60 seconds. Also, looking that > the FreeBSD 3.2 sources which are very close to the code used to port the > stack we use, I'm pretty sure can see where the timeout is set to 2 times > the Maximum Segment Lifetime which would be 2 minutes on a system with the > default settings. I would expect lingertime or realslow to impact FIN_WAIT_2. Does neither? realslow sets the time in ticks for closing slow TW connections, and I thought that FIN_WAIT_2 implied a slow connection (I need to pull that book off the shelf when I get home, I guess). >> I add, that i've seen that even closing apache the hundreds of sockets >> stay in FIN_WAIT_2 and do not disappear > How long did you wait? I would not be surprised if the timeout was 2 > minutes. > Indeed, these will hang around for some time after Apache closes, as Apache itself is not using them and has essentially abandoned them (it already issued a close(), so issuing another would be a waste of time). > You can try the attached and see if it can deal with the sockets stuck in > FIN_WAIT_2. It's basically a manual version of socktidy. Run it as > CloseSocket and give it a list of sockets to close. > > I've never tested it against FIN_WAIT_2 sockets, so it might have no > ettect. > I think once the socket number is returned to the pool, identifying these "cling-ons" (Klingons?) will be tricky. However, as you mentioned earlier, I would expect the BSD 3.2 stack to have a timeout setting for these, which was why I suspect lingertime or realslow to do the trick. Now I'll have to look at the 3.2 sources myself. As you are wont to say, some people do crossword puzzles... LOL -- Lewis ------------------------------------------------------------- Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLC www.2rosenthals.com visit my IT blog www.2rosenthals.net/wordpress -------------------------------------------------------------