From: "Massimo S." <ecs-isp@2rosenthals.com>
Reply-To: ml@ecomstation.it
Subject: Re: [eCS-ISP] socket - no buffer space availble
To: eCS ISP Mailing List <ecs-isp@2rosenthals.com>
References: <list-13710656@2rosenthals.com> <list-13711073@2rosenthals.com>
 <list-13711107@2rosenthals.com>
Organization: Massimo S.
Message-ID: <b4a53a27-500f-bca4-a694-2e3b70d33dd8@ecomstation.it>
Date: Mon, 28 Jul 2025 20:44:49 +0200
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; it-IT; rv:1.7.13) Gecko/20060424
 Thunderbird/1.0.8 Mnenhy/0.7.4.0
MIME-Version: 1.0
In-Reply-To: <list-13711107@2rosenthals.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: it
Content-Transfer-Encoding: 7bit



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.
> 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 ..

massimo