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 13711213 for ecs-isp@2rosenthals.com; Mon, 28 Jul 2025 15:05:49 -0400 Subject: Re: [eCS-ISP] socket - no buffer space availble To: eCS ISP Mailing List References: Organization: Rosenthal & Rosenthal, LLC Message-ID: <6887CA0B.6050402@2rosenthals.com> Date: Mon, 28 Jul 2025 15:05:47 -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 Two clarifications: On 07/28/25 02:44 pm, Massimo S. wrote: > > > Il 28/07/2025 19:18, Massimo S. ha scritto: >> >> >> Il 28/07/2025 18:44, Lewis G Rosenthal ha scritto: >>> Hi, Max... >>> >>> On 07/28/25 05:52 am, Massimo S. wrote: >>>> Hi all, >>>> >>>> sometime this happens on a couple of VMs here: >>>> >>>> netstat -r (or other commands) give the output in the subject. >>>> >>>> >>>> Of course is there anything that i can do other than the setboot /b ? >>>> Any suggestion? >>>> Thanks. >>>> >>>> (This happens on an AOS VM and also on eCS2.2b VM) >>> >>> This is an elephant gun solution (reboot) to a very common problem. >>> >>> When you run out of network buffers, something is likely leaking network >>> buffers (i.e., using them and not returning them to the pool when >>> finished). >>> >>> You should start closing applications one at a time until the number of >>> available buffers returns to a more normal level (netstat -m is your >>> friend), then restart those applications. Either there is a >>> configuration setting which might be changed or a defect in the code >>> causing this. >>> >>> Buffer usage is often hard to predict, but it should ebb and flow with >>> network traffic. If it doesn't, there is something not giving them back >>> to the pool for some reason. >>> >>> Also, netstat -i will give you a count of packets lost due to no buffers >>> available (and other unusual happenings). >>> >>> Something else you can try (half an elephant gun) is running socktidy >>> and stopping it. This will close those unused sockets consuming buffer >>> space. However, this will not fix the underlying problem (too many >>> connections allowed for something?). It will save you a reboot. As a >>> working kludge, you could run socktidy once every few hours to dump the >>> cruft. >>> >>> As a rule, I do not run socktidy on servers because it can interrupt the >>> flow of some slow connections which might need to remain open a bit >>> longer. It's fine on workstations, however. >>> >>> A final thought would be to trim your tcprwinsize. If you are using >>> something above the default, then lower it a few bytes at a time while >>> monitoring the situation over the course of a few days. Larger window >>> sizes consume more buffers. >>> >>> The OS/2 IPv4 stack is quite robust. The venerable BSD on which it is >>> based (in fact, from which it was ported nearly verbatim) runs many, >>> many boxes to this day. Sadly, as with old car restoration, there are >>> fewer and fewer of us around who have taken the time over the years to >>> learn the basic concepts of the system and who understand how the >>> various parts of the stack fit together (not the "Windows way"). >>> >>> HTH Food for thought, at least. >>> >>> Cheers >> >> Hi Lewis, >> >> my VMs do nightly reboot and of course are servers (eg. apache web server). >> So i can't use socktidy. Run it briefly and then stop it. It won't interrupt your traffic more than restarting Apache. Note that I specifically said that I don't run it on servers (run=continually). >> Apache itself get scheduled restarts 2 or 3 times per day. >> And there are FW rules that close, i don't recall exactly, 25 or 30 >> concurrent connections from the same IP, other than a lot of rules >> that close unwanted crawlers, http/https attacks etc. >> >> massimo > > yes, apache.. > > [Sat Jul 27 14:35:38.685000 2024] [core:crit] [pid 2784:tid 1] (OS > 10055)No buffer space available: AH00078: alloc_listener: failed to get a > socket for .. > This is just reporting the result of running out of sockets/buffers. It may not even be Apache which is consuming them. If it is, try lowering the max connections and see if that makes a difference. -- Lewis ------------------------------------------------------------- Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLC www.2rosenthals.com visit my IT blog www.2rosenthals.net/wordpress -------------------------------------------------------------