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?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FSM: Fold, Spindle and Mutilate
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. IIRC the security stuff gets applied when you first start your login session, and the permissions more or less get inherited by everything thereafter (i.e. processes forked from your initial login shell process).
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.
Dave
On 2023-01-03, at 4:40 PM, David T. Lewis lewis@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@rowledge.org; http://www.rowledge.org/tim APATHY ERROR: Don't bother striking any key.
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@rowledge.org wrote:
On 2023-01-03, at 4:40 PM, David T. Lewis lewis@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@rowledge.org; http://www.rowledge.org/tim APATHY ERROR: Don't bother striking any key.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Do you like me for my brain or my baud?
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@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@rowledge.org wrote:
On 2023-01-03, at 4:40 PM, David T. Lewis lewis@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@rowledge.org; http://www.rowledge.org/tim APATHY ERROR: Don't bother striking any key.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Do you like me for my brain or my baud?
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@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@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@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@rowledge.org wrote:
On 2023-01-03, at 4:40 PM, David T. Lewis lewis@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@rowledge.org; http://www.rowledge.org/tim APATHY ERROR: Don't bother striking any key.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Do you like me for my brain or my baud?
After looking at various file in the /etc/pam.d directory, I also tried adding the session required pam_limits.so line into the - /etc/pam.d/common-session - /etc/pam.d/tigervnc file
... with no visible effect.
And between each attempt I actually rebooted the machine, so it's definitely getting it's chance.
So the current status is that - if I log in via ssh from my iMac, the ulimit -r result is what we want - if I try from a terminal running via the VNC desktop, it is not what we want. - if Squeak is run within a systemd file, it works by virtue of the LimitRTPRIO=2 command
The system is x64 xubuntu with tigerVNC added. It may be of note that tigerVNC is running from a systemd file and that it seems to stop occasionally and require a manual restart.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Full of wisdumb.
The only additional suggestion I've received that might possibly make some sense is "is this an issue of login vs non-login shell?" Does that trigger any ideas for anyone?
And possibly of some value, I note that the config of Raspberry Pi OS does not have this problem; connecting via VNC results in an environment where the ulimit -r value is what we need. I tried poking around at the assorted directories but the limits and pam stuff are sufficiently different that it makes no sense to me.
On 2023-01-04, at 3:02 PM, tim Rowledge tim@rowledge.org wrote:
After looking at various file in the /etc/pam.d directory, I also tried adding the session required pam_limits.so line into the
- /etc/pam.d/common-session
- /etc/pam.d/tigervnc file
... with no visible effect.
And between each attempt I actually rebooted the machine, so it's definitely getting it's chance.
So the current status is that
- if I log in via ssh from my iMac, the ulimit -r result is what we want
- if I try from a terminal running via the VNC desktop, it is not what we want.
- if Squeak is run within a systemd file, it works by virtue of the LimitRTPRIO=2 command
The system is x64 xubuntu with tigerVNC added. It may be of note that tigerVNC is running from a systemd file and that it seems to stop occasionally and require a manual restart.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Full of wisdumb.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SEOB: Set Every Other Bit
Hi,
So by the time that the shell is started, and whether or not it is a login shell is determined, pam has finished all of her work.
A bit of probably pointless background.
pam was designed so that there were pluggable ways of expanding how authentication and authorisation is done at login. This way you can authenticate with a password and authorise with /etc/passwd and /etc/groups like we old timers do. Or you can authenticate with ldap and authorise with a local set of groups, or use Active Directory for authentication and then ldap for authorisation, etc.
The limits setting is in the authorisation step. A quick look on my ubuntu based system shows that limits is called fo:
* cron
* lightdm - the GUI login manger.
* sshd - for ssh
* su
* sudo
Where on my PI it is called for
* cron
* lightdm
* login
* sshd
* su
* vncserver.
Now I use xrdp and it is not called in that case and I have tested that limits are not set.
I'm guessing if one added in the line
session optional pam_limits.so
to which ever file is the vnc server file in /etc/pam.d on your ubuntu it would work.
cheers
bruce
On 2023-01-09T03:09:14.000+01:00, tim Rowledge tim@rowledge.org wrote:
The only additional suggestion I've received that might possibly make some sense is "is this an issue of login vs non-login shell?" Does that trigger any ideas for anyone? And possibly of some value, I note that the config of Raspberry Pi OS does not have this problem; connecting via VNC results in an environment where the ulimit -r value is what we need. I tried poking around at the assorted directories but the limits and pam stuff are sufficiently different that it makes no sense to me.
On 2023-01-04, at 3:02 PM, tim Rowledge tim@rowledge.org wrote: After looking at various file in the /etc/pam.d directory, I also tried adding the session required pam_limits.so [http://limits.so] line into the - /etc/pam.d/common-session - /etc/pam.d/tigervnc file ... with no visible effect. And between each attempt I actually rebooted the machine, so it's definitely getting it's chance. So the current status is that - if I log in via ssh from my iMac, the ulimit -r result is what we want - if I try from a terminal running via the VNC desktop, it is not what we want. - if Squeak is run within a systemd file, it works by virtue of the LimitRTPRIO=2 command The system is x64 xubuntu with tigerVNC added. It may be of note that tigerVNC is running from a systemd file and that it seems to stop occasionally and require a manual restart. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Full of wisdumb.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SEOB: Set Every Other Bit
Thanks for the explanations - unfortunately adding that line didn't make any difference at all!
I tried adding a nonsense line to see if anything would be reported in the auth.log (or indeed the system lg, the dmesg, anything I could find) and... nothing.
I did find one online report of the inverse problem - the user could set ulimits when logged in via VNC but *not* when ssh loggedin . That didn't help either :-(
This really is weird...
Are there no other listers using ubuntu via VNC?
On 2023-01-08, at 11:44 PM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
So by the time that the shell is started, and whether or not it is a login shell is determined, pam has finished all of her work.
A bit of probably pointless background.
pam was designed so that there were pluggable ways of expanding how authentication and authorisation is done at login. This way you can authenticate with a password and authorise with /etc/passwd and /etc/groups like we old timers do. Or you can authenticate with ldap and authorise with a local set of groups, or use Active Directory for authentication and then ldap for authorisation, etc.
The limits setting is in the authorisation step. A quick look on my ubuntu based system shows that limits is called fo:
- cron
- lightdm - the GUI login manger.
- sshd - for ssh
- su
- sudo
Where on my PI it is called for
- cron
- lightdm
- login
- sshd
- su
- vncserver.
Now I use xrdp and it is not called in that case and I have tested that limits are not set.
I'm guessing if one added in the line
session optional pam_limits.so
to which ever file is the vnc server file in /etc/pam.d on your ubuntu it would work.
cheers bruce On 2023-01-09T03:09:14.000+01:00, tim Rowledge tim@rowledge.org wrote: The only additional suggestion I've received that might possibly make some sense is "is this an issue of login vs non-login shell?" Does that trigger any ideas for anyone?
And possibly of some value, I note that the config of Raspberry Pi OS does not have this problem; connecting via VNC results in an environment where the ulimit -r value is what we need. I tried poking around at the assorted directories but the limits and pam stuff are sufficiently different that it makes no sense to me.
On 2023-01-04, at 3:02 PM, tim Rowledge tim@rowledge.org wrote:
After looking at various file in the /etc/pam.d directory, I also tried adding the session required pam_limits.so line into the
- /etc/pam.d/common-session
- /etc/pam.d/tigervnc file
... with no visible effect.
And between each attempt I actually rebooted the machine, so it's definitely getting it's chance.
So the current status is that
- if I log in via ssh from my iMac, the ulimit -r result is what we want
- if I try from a terminal running via the VNC desktop, it is not what we want.
- if Squeak is run within a systemd file, it works by virtue of the LimitRTPRIO=2 command
The system is x64 xubuntu with tigerVNC added. It may be of note that tigerVNC is running from a systemd file and that it seems to stop occasionally and require a manual restart.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Full of wisdumb.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SEOB: Set Every Other Bit
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim boutique - a startling hardwood
Hi - not to be stupid but you did restart the VNC server when you did this, right? Rebooting would guarantee this. And then I don't know.
cheers
bruce
On 2023-01-09T20:46:36.000+01:00, tim Rowledge tim@rowledge.org wrote:
Thanks for the explanations - unfortunately adding that line didn't make any difference at all! I tried adding a nonsense line to see if anything would be reported in the auth.log (or indeed the system lg, the dmesg, anything I could find) and... nothing. I did find one online report of the inverse problem - the user could set ulimits when logged in via VNC but *not* when ssh loggedin . That didn't help either :-( This really is weird... Are there no other listers using ubuntu via VNC?
On 2023-01-08, at 11:44 PM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote: Hi, So by the time that the shell is started, and whether or not it is a login shell is determined, pam has finished all of her work. A bit of probably pointless background. pam was designed so that there were pluggable ways of expanding how authentication and authorisation is done at login. This way you can authenticate with a password and authorise with /etc/passwd and /etc/groups like we old timers do. Or you can authenticate with ldap and authorise with a local set of groups, or use Active Directory for authentication and then ldap for authorisation, etc. The limits setting is in the authorisation step. A quick look on my ubuntu based system shows that limits is called fo: * cron * lightdm - the GUI login manger. * sshd - for ssh * su * sudo Where on my PI it is called for * cron * lightdm * login * sshd * su * vncserver. Now I use xrdp and it is not called in that case and I have tested that limits are not set. I'm guessing if one added in the line session optional pam_limits.so [http://limits.so] to which ever file is the vnc server file in /etc/pam.d on your ubuntu it would work. cheers bruce On 2023-01-09T03:09:14.000+01:00, tim Rowledge tim@rowledge.org wrote: The only additional suggestion I've received that might possibly make some sense is "is this an issue of login vs non-login shell?" Does that trigger any ideas for anyone? And possibly of some value, I note that the config of Raspberry Pi OS does not have this problem; connecting via VNC results in an environment where the ulimit -r value is what we need. I tried poking around at the assorted directories but the limits and pam stuff are sufficiently different that it makes no sense to me. On 2023-01-04, at 3:02 PM, tim Rowledge tim@rowledge.org wrote: After looking at various file in the /etc/pam.d directory, I also tried adding the session required pam_limits.so [http://limits.so] line into the - /etc/pam.d/common-session - /etc/pam.d/tigervnc file ... with no visible effect. And between each attempt I actually rebooted the machine, so it's definitely getting it's chance. So the current status is that - if I log in via ssh from my iMac, the ulimit -r result is what we want - if I try from a terminal running via the VNC desktop, it is not what we want. - if Squeak is run within a systemd file, it works by virtue of the LimitRTPRIO=2 command The system is x64 xubuntu with tigerVNC added. It may be of note that tigerVNC is running from a systemd file and that it seems to stop occasionally and require a manual restart. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Full of wisdumb. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SEOB: Set Every Other Bit
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim boutique - a startling hardwood
On 2023-01-10, at 4:57 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi - not to be stupid but you did restart the VNC server when you did this, right? Rebooting would guarantee this.
Oh yeah, full machine reboot each time.
And then I don't know.
Me neither. This is very confusing and annoying.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Old programmers never die; they just branch to a new address.
So I have spent some time looking at the Tigervnc site and the RedHat documentation and now I am confused.
When you connect to the VNC Server you don't login with your username and password, do you? You actually use some special VNC password, right? So the VNC server is already running, as your user, right and the password is just fo allow the connection?
If so, that is probably key because that means that you are not running PAM.
If the above is true what happens if you do not have the VNC server start automagically, and rather set it up so you login via ssh and start it manually? If you do that, since ssh obeys limits then processes started from an ssh session should obey as well and then your VNC session should have the right limits.
On 2023-01-10T18:56:17.000+01:00, tim Rowledge tim@rowledge.org wrote:
On 2023-01-10, at 4:57 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote: Hi - not to be stupid but you did restart the VNC server when you did this, right? Rebooting would guarantee this.
Oh yeah, full machine reboot each time.
And then I don't know.
Me neither. This is very confusing and annoying. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Old programmers never die; they just branch to a new address.
squeak-dev@lists.squeakfoundation.org