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>
Organization: Massimo S.
Message-ID: <d6a3d9f5-41c5-e3af-62fd-892d3eea7b59@ecomstation.it>
Date: Mon, 28 Jul 2025 19:18:50 +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-13711073@2rosenthals.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: it
Content-Transfer-Encoding: 7bit



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