Hi,

In what has to be the most frustrating response, it works for me...

This would be on a Linux (Linux Mint 21.1) which is basically a Ubuntu
22.04.

So the message comes from 

7859  sched_setscheduler(7859, SCHED_FIFO, [1]) = -1 EPERM (Operation
not permitted)

which you can get by prepending

strace -f -o /tmp/zz.log  yoursqueakcommandlinehere

and then look at zz.tmp

The number at the beginning is not so important.  That EPERM is what
triggers the message.

If it returns 0 then all was happy.

In my case putting exactly the file requested in place (owned by root,
644 permissions) fixes it.

One simple way you can check is to type the command

ulimit -r

if it returns 2 then the file was processed when you logged in.

Otherwise it returns the default of 0.

So it does not work for Tim and that means debugging pam.  Hold on
while I go roll around in nettles for a while without clothes, it is
more fun and way less painful.

1. put the lines that you have in squeak.conf in
/etc/security/limits.conf instead.  Maybe your pam_limits setup does
not read limits.d directory.  Perchance does /etc/limits exist?  Ah,
you have an old system.  Put the same lines in /etc/limits.

2. if that does not work, does the file /etc/pam.d/login exist?  If
so, does it seem to reference limits?  Mine limits section looks like

# Sets up user limits according to /etc/security/limits.conf

# (Replaces the use of /etc/limits in old login)

session    required   pam_limits.so

3.  So do you sit at the console of this ubuntu system?  No, try
logging in from the console and see if that works?

4.  If you do not sit at the console, and can't sit at the console
try just a ssh into the box.  What then does ulimit -r show?  Still
0?

At this point there should be one of two cases.

1. You never see ulimit -r showing 2 regardless of whether you login
via ssh, the console, or how ever you login normally.

2.  You see ulimit -r showing 2 but only sometimes, not when you
login like you want to login.

If it is the the first case then somehow the pam_limits module is not
working.  I have not seen this but it is always possible.  And I
don't know how to fix this other than "start reading those horrid
instructions about debugging pam."  Do note that if you break pam you
will no longer be logging in so have some recovery pre-planned in this
case.  I would strongly recommend just redirecting stderr to some
file in /tmp and ignoring the problem.   It should only be annoying
when your system is heavily loaded. 

If it is case 2 then you are half in luck.  You then need to figure
out which one of the files in /etc/pam.d you are actually using rather
than login and fixing that.  My memory from the last time I had to
play with this was that login was always run when you logged in, but,
that could have changed....

Does this at least help somewhat?

cheers

bruce

On 2023-01-04T02:09:10.000+01:00, tim Rowledge <tim at rowledge.org>
wrote:

> 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230104/c293d0e2/attachment.html>