An aside that might trigger someone's memory - using the VM via a systemd unit file with 'LimitRTPRIO=2' appears to let the thread spawning do its thing.

In `top` with threads displayed I see - 
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                          
   1525 sagetea+  20   0  176396 112684   7240 S   2.7   0.7   8:21.60 squeak                                            
   1555 sagetea+  -2   0  176396 112684   7240 S   0.7   0.7   2:48.85 squeak  

Whereas for a VM run 'normally'

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                          
   4939 tim       20   0  266748 113184   7760 S   4.0   0.7   0:01.79 squeak                                            
   4959 tim       20   0  266748 113184   7760 S   1.0   0.7   0:00.34 squeak                                            
   4954 tim       20   0  266748 113184   7760 S   0.0   0.7   0:00.00 squeak                                            
   4955 tim       20   0  266748 113184   7760 S   0.0   0.7   0:00.00 squeak                                            


Which definitely looks different. Why the three threads? Why are two never showing anything under the TIME column?      

> On 2023-01-03, at 4:50 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 2023-01-03, at 4:40 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>> 
>> On Tue, Jan 03, 2023 at 03:35:37PM -0800, tim Rowledge wrote:
>>> This has been annoying me for some time but since I'm waiting for yet another TestRunner run I have a moment to whine about it.
>>> 
>>> On my Pi I have no problems with the /etc/security/limits.d/squeak.conf file. Well, none that I know of. If I run a system from commandline there is no complaint about it.
>>> 
>>> On my x86 ubuntu machine I created the file. It has the same permissions as on the pi, and the same content, and the owner in both cases is root. If I run a system from a commandline the first thing I see is a complaint about needing the damn file!
>>> 
>>> What can I do to solve this? Is it simply the VM code being mistaken? Is there some other ubuntu related security dance we have to do?
>>> 
>> 
>> Log out completely from your shell session, and then log back in. 
> 
> Oh, done that many times with no change in result :-(
> 
>> 
>> If that doesn't work, unplug the computer and wait for the disk drive
>> to come to a complete halt, wait another 30 seconds, then plug it back
>> in and see if it starts working. Just kidding, kinda.
> 
> Tried that several times too. This is really weird.
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> APATHY ERROR:  Don't bother striking any key.
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Do you like me for my brain or my baud?