> On 8. Oct 2022, at 16:37, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 
> On Fri, Oct 07, 2022 at 06:00:21PM -0500, Chris Muller wrote:
>> I'm 98% certain the issue is the new memory monitor running
>> 
>>   OSProcess outputOf: 'cat /proc/meminfo'
>> 
>> every 5 seconds.  It automatically disables on any Error.  Unfortunately,
>> #outputOf: appears to have a slow resource leak that causes a slow grind to
>> a halt -- never signaling any Errors, and never crashing.  My attempt to
>> make the server more resilient has ironically resulted in it being more
>> fragile.
>> 
>> So, I think I'm going to try going back to my old method which uses
>> #command:
>> 
>>     OSProcess command: 'cat /proc/meminfo -> meminfo.out'
>> 
>> and then parsing meminfo.out.  I'm hopeful #command: will not have the same
>> issue.
>> 
> 
> Hi Chris,
> 
> That's a lot of OSProcess/CommandShell invocations, over 17 thousand
> per day. Each one is setting up three pipe connections (six file
> descriptors), and each requires the unix signal handler to clean up
> the exited child and close open pipe handles. I would not be too
> surprised if intermittent problems were to accumulate over time at
> that rate (missed unix signals under heavy load? I don't know).
> 
> If the file descriptor leak is associated with OSProcess, you will see
> pipe entries accumulating in /proc/<pid>/fd. If the leak is coming from
> SqueakSource stuff, you will see socket handles. Let's keep an eye on
> it and see which it is. I think your intuition is right but we may as
> well confirm it.

Also why not simply reading the file? Like with filestream…

Best regards
	-Tobias