Poštni seznam arhiviranih sporo?il

Od:	"Lewis G Rosenthal" <ecs-isp@2rosenthals.com>	Glava Izvorno E-sporo?ilo
Zadeva:	Re: [eCS-ISP] socket - no buffer space availble
Datum:	Wed, 30 Jul 2025 11:54:16 -0400
Za:	eCS ISP Mailing List <ecs-isp@2rosenthals.com>

Hi... On 07/29/25 07:25 pm, Steven Levine wrote: In <list-13712173@2rosenthals.com>, on 07/29/25 at 07:45 PM, "Massimo S." <ecs-isp@2rosenthals.com> 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 -------------------------------------------------------------

Naro?iti: Poro?ilo (Feed), Izvle?ek (Digest), Indeks.
Odjava
E-pošta za mojstra za sezname