Hi,

Replying to the list so that some record is kept...

Tim's issue is that he uses VNC, TigerVNC I believe, and it is not
running the limits pam module.

I use XRDP and it has the same problem.

So at least we understand where the problem is, but, not the
solution.  Yet...

Thanks.

cheers

bruce

On 2023-01-04T21:34:57.000+01:00, rabbit <rabbit at callistohouse.org>
wrote:

> Thanks, Bruce, this change to limits.conf worked for me. <Ubuntu
> 22.04>
> 
> •••
> 𝙄𝙛 𝙮𝙤𝙪 𝙖𝙧𝙚 𝙙𝙧𝙞𝙫𝙞𝙣𝙜 𝙖
> 𝙋𝙤𝙧𝙨𝙘𝙝𝙚, 𝙩𝙝𝙖𝙣𝙠 𝙮𝙤𝙪
> 𝙛𝙤𝙧 
> 𝙢𝙤𝙫𝙞𝙣𝙜 𝙤𝙫𝙚𝙧, 𝙨𝙤 𝙩𝙝𝙖𝙩
> 𝙄 𝙘𝙤𝙪𝙡𝙙 𝙨𝙖𝙛𝙚𝙡𝙮
> 𝙥𝙖𝙨𝙨! 
> _ARRIVEDERCI, RABBIT • D_𝙖𝙩𝙨𝙪𝙣 𝟮𝟰𝟬𝙕
> • 🐰
> 
>>  On Jan 4, 2023, at 05:17, Bruce O'Neel <bruce.oneel at pckswarms.ch>
>>  wrote:
> 
>>  
>>  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 [http://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/d6a1bd51/attachment.html>