[OpenSmalltalk/opensmalltalk-vm] Do not use linux-latest runner, use an older stable version. (#598)
A VM compiled on ubuntu-20.04 (aka latest) will not run on ubuntu-16.04 due to runtime library link issues. Therefore select ubuntu-18.04 as a build runner that is likely to support a wider range of existing Linux systems. Addresses this problem:
/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/598
-- Commit Summary --
* <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/598/commits/783c850d27680f23220d3acac430aa08afad1c3e">Do not use linux-latest runner, use an older stable version.</a>
-- File Changes --
M .github/workflows/linux.yml (2)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/598.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/598.diff
@marceltaeumel pushed 1 commit.
528ce2787b80d50ef1dbe480bd8867e92981d085 Do not try to load libllvm12:i386 on ubuntu-18.04
Not sure how easy this will be. The first error looks weird: ``` /usr/lib/x86_64-linux-gnu/libfreetype.so: error adding symbols: File in wrong format ```
Ubuntu 18.04 does not make it easy for me.
First, I encountered a strange issue in `apt install` where dependency resolution for the 32-bit package `libpango1.0-dev:i386` did not work. I had to first check `libharfbuzz-dev:i386` and finally ` libicu-dev:i386` to make the pango library install as expected.
Second, `make configure` failed with a `error: possibly undefined macro: LT_LIB_DLLOAD`. I had to manually install `libltdl-dev` ... `libtool` was apparently not enough. See "scripts/ci/actions_prepare_linux_x86.sh" for the usual list.
And finally, I cannot even build "squeak.cog.spur" for "linux64x64" because linking fails. It's again about the pango library:
``` opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build/libtool --mode=link gcc -Wall -g -O2 -DNDEBUG -DDEBUGVM=0 -msse2 -DCOGMTVM=0 -pthread -DLSB_FIRST=1 -m64 -L/usr/local/lib -Wl,-z,now -lpangocairo-1.0 -lcairo -lpango-1.0 -lgobject-2.0 -lglib-2.0 -avoid-version -module -rpath /home/marcel/src/opensmalltalk-vm/products/sqcogspur64linuxht/lib/squeak/`/home/marcel/src/opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build/getversion VERSION_TAG` -o UnicodePlugin.la UnicodePlugin.lo UnicodeOps-linux.lo libtool: link: gcc -shared -fPIC -DPIC .libs/UnicodePlugin.o .libs/UnicodeOps-linux.o -L/usr/local/lib -lpangocairo-1.0 -lcairo -lpango-1.0 -lgobject-2.0 -lglib-2.0 -g -O2 -msse2 -pthread -m64 -Wl,-z -Wl,now -pthread -Wl,-soname -Wl,UnicodePlugin.so -o .libs/UnicodePlugin.so /usr/bin/ld: cannot find -lpangocairo-1.0 /usr/bin/ld: cannot find -lpango-1.0 collect2: error: ld returned 1 exit status Makefile:174: recipe for target 'UnicodePlugin.la' failed ```
Not sure about that "autoconf" incident, but something fishy might be going on with pango in Ubuntu 18.04.
The only possible comfort I can offer here is that I was able to build an x86 vm for linux to support the "Raspberry Pi Desktop for x86" distro. That runs the NuScratch, of course. And it requires the unicode plugin.
The annoying thing is that I can't find any mail/notes about this, so I'm unable to point to any particular solutions I found.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- L'ETAT, C'EST MOE - All the world's a stooge
I am now looking at the hardcoded magic in "platforms/unix/plugins/UnicodePlugin/README.UnicodePlugin". Maybe this is the reason why the VM binaries did not play so well in the first place? Maybe we can use Ubuntu 20.04 after all?
Okay. We don't even build the "UnicodePlugin" in the CI because: ``` 2021-09-22T23:04:54.3201231Z checking for PangoCairo libraries... no 2021-09-22T23:04:54.3202551Z ******** disabling UnicodePlugin ```
But in both Ubuntu 18.04 and 20.04, we have them loaded by default. Hmm.... anyway. Both "FT2Plugin" and "UnicodePlugin" are currently not built in the CI with Ubuntu 20.04 but somehow here when using Ubuntu 18.04.
With respect to UnicodePlugin, we may be seeing an interaction with some changes in PR#585, specifically the changes to UnicodePlugin/Makefile.inc and UnicodePlugin/acinclude.m4 (thanks Phil B for the pointer). Prior to merging PR#585, I had noticed that UnicodePlugin was failing for the 32-bit builds on my old Ubuntu 16.04 system. However, it built cleanly on the CI, so I chose to overlook that issue at the time. Now we see that UnicodePlugin build is failing on CI when we specify an Ubuntu 18.04 (not bleeding edge, not ancient, sort of middle of the road) build runner. This suggest that we need to look more carefully at the changes to those two files in https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/585/files#diff-722b7a...
As @dtlewis290 suggests, I think it's reasonable to look at my 585 changes as being the culprit. I changed Makefile.inc / acinclude.m4 to add _-I/usr/lib/x86_64-linux-gnu/glib-2.0/include_ when I saw that UnicodePlugin was failing to be configured on 64-bit Debian due to autoconf not finding a needed header. This resolved the issue on my Debian build VMs but these were not multiarch enabled (i.e. I had *either* a 32-bit or 64-bit build environment, not a combined one) so I suspect the problem might be with multiarch build environments having both 32-bit and 64-bit PangoCairo-related libraries installed at the same time? If that's the case, one solution could be to have the 'build for platform' detection append the include path to only the appropriate /usr/lib/<arch>/glib-2.0/include directory rather than both which should eliminate any conflict on multiarch enabled systems. If the issue isn't related to multiarch then I'm not sure what the cause is.
Probably we should actually follow GLibs requirements and use `pkg-config`? [This seems appropriate](https://stackoverflow.com/questions/1732822/portably-include-glib-headers-in...):
By using the `PKG_CHECK_MODULES` macro, Autoconf-generated configure scripts can retrieve pkg-config data automatically. […]
PKG_CHECK_MODULES([DEPS], [glib-2.0 >= 2.24.1])
Or step by step: https://stackoverflow.com/a/14828132
However, these all assume automake, but we dont use that. I'll have a look…
(Actually, David's notes in the Readme seem pretty acurate)
see ea296f0
@marceltaeumel pushed 1 commit.
a9619d83c9adb69f32f53caca14b9c92033b3528 Merge remote-tracking branch 'upstream/Cog' into dtl/linux-runs-on-setting
@marceltaeumel pushed 2 commits.
e0e2198baa9380c7fb5d394a132860c6605c33a2 Merge remote-tracking branch 'upstream/Cog' into dtl/linux-runs-on-setting 0cce8a8a06d1128d24dcbce27a8a1015b7ab4ec4 Use architecture-specific pkg-config to also find the right include paths for 32-bit libraries.
@marceltaeumel pushed 1 commit.
fae103c23be02ffe63dc565501c1e6d2e66e531b Unload pre-loaded libfreetype6-dev (64-bit) (such as on Ubuntu 18.04) to avoid linking errors on 32-bit builds.
@marceltaeumel pushed 1 commit.
8b2c633483ba209ec6c1cc93e112242bc982121d Fix syntax error. Sorry for the noise.
@marceltaeumel pushed 1 commit.
bac32e38fde7df13992034670777235ac1ad2721 Set PKG_CONFIG with a full /usr/bin/ path to not be overwritten again.
@marceltaeumel pushed 1 commit.
2c67883bcba54442c3b4ccd49644df875532ccb1 Always use generic "pkg-config" except for 32-bit x86 builds. Note that also our ARMv6 and ARMv8 setup works with "pkg-config". Just linux32x86 builds need "i686-linux-gnu-pkg-config" to find the right paths.
Here is what we should check before merging: [ ] linux32x86-squeak.cog.spur includes the UnicodePlugin [ ] linux64x64-squeak.cog.spur includes the UnicodePlugin [ ] linux32ARMv6-squeak.cog.spur includes the UnicodePlugin [ ] linux64ARMv8-squeak.cog.spur includes the UnicodePlugin [ ] linux32x86-pharo.cog.spur includes the FT2Plugin [ ] linux64x64-pharo.cog.spur includes the FT2Plugin
Confirming - the CI build artifact now runs successfully on my Ubuntu 16.04 LTS system. Previously the VM would fail due to link errors as originally reported. These VMs should now run on a wider range of existing Linux machines.
This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His shared libraries aren't installed.
I am on slackware and have the same issue. If I su to root and run squeak, it goes away.
Ubuntu dont root, but it do su, so try su squeak.sh
---- On Tue, 28 Sep 2021 18:12:29 -0400 tim@rowledge.org wrote ----
This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His shared libraries aren't installed.
Hi
On 29. Sep 2021, at 00:12, tim Rowledge tim@rowledge.org wrote:
This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
this file only takes action when pam_limits is used. can you grep your /etc/pam.d for limits?
Best regards -Tobias
PS: I hate to say it, but it seems the neat architecture of the heartbeat-VM is not appreciated by current linux distros. There is just too much to do for the average user to make use of it. Also, users need some kind of Root to be able to enable the rtprio, which is not a good idea. Is there any way to get away without changing rtprio?
Hi,
So on my ubuntu derived system, if I put /etc/security/limits.d/squeak.conf in place, reboot the system, and log in it does work. Rebooting the system is key in my case because the window manager login process only reads squeak.conf when restarted.
So this means that we are stuck with different choices of config files in /etc/pam.d that might, or might not, have to be changed to make this work. And which files will be window manager dependent etc.
This is not a good plan to throw at our users. Modifying the contents of /etc/pam.d is fraught with problems if you don't know what you are doing. In fact it is fraught with problems even if you do. Everytime I have to do this I make sure that I have a root shell already on the system so that I can unfoobar the system when I break it.
I would vote that we get rid of this complaint and document somewhere the limits.d/squeak.conf idea. I suspect that most people who use squeak with a display do not have heavily loaded systems and it is only useful for those of us who run servers. And if they ever ask we have documentation.
One place we could stick this is in the About squeak dialog. Call it FAQ?
cheers
bruce
On 2021-09-29T08:24:23.000+02:00, Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 29. Sep 2021, at 00:12, tim Rowledge tim@rowledge.org wrote: This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'. I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
this file only takes action when pam_limits is used. can you grep your /etc/pam.d for limits? Best regards -Tobias PS: I hate to say it, but it seems the neat architecture of the heartbeat-VM is not appreciated by current linux distros. There is just too much to do for the average user to make use of it. Also, users need some kind of Root to be able to enable the rtprio, which is not a good idea. Is there any way to get away without changing rtprio?
A tangential FYI: the Debian packaging will be taking care of this as part of the installation. Currently it installs the /etc/security/limits.d/squeak.conf file and I'll look into adding the pam.d part as well.
Of course if there's a way to get the functionality without the config tweaking, that would be even better. If not, well that's one of the many reasons we have packages ;-)
On Wed, Sep 29, 2021 at 2:24 AM Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 29. Sep 2021, at 00:12, tim Rowledge tim@rowledge.org wrote:
This reminds me to ask (probably again) if anyone actually understands
ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it
appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain.
I've spent way too long trying to make sense of what I find with
googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
this file only takes action when pam_limits is used. can you grep your /etc/pam.d for limits?
Best regards -Tobias
PS: I hate to say it, but it seems the neat architecture of the heartbeat-VM is not appreciated by current linux distros. There is just too much to do for the average user to make use of it. Also, users need some kind of Root to be able to enable the rtprio, which is not a good idea. Is there any way to get away without changing rtprio?
Hi,
This is exactly the right solution for a package manager. This will be very good.
cheers
bruce
On 2021-09-29T15:59:29.000+02:00, Phil B pbpublist@gmail.com wrote:
------------------------- A tangential FYI: the Debian packaging will be taking care of this as part of the installation. Currently it installs the /etc/security/limits.d/squeak.conf file and I'll look into adding the pam.d part as well. Of course if there's a way to get the functionality without the config tweaking, that would be even better. If not, well that's one of the many reasons we have packages ;-) On Wed, Sep 29, 2021 at 2:24 AM Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 29. Sep 2021, at 00:12, tim Rowledge tim@rowledge.org
wrote:
This reminds me to ask (probably again) if anyone actually
understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but
it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain.
I've spent way too long trying to make sense of what I find with
googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it. this file only takes action when pam_limits is used. can you grep your /etc/pam.d for limits? Best regards -Tobias PS: I hate to say it, but it seems the neat architecture of the heartbeat-VM is not appreciated by current linux distros. There is just too much to do for the average user to make use of it. Also, users need some kind of Root to be able to enable the rtprio, which is not a good idea. Is there any way to get away without changing rtprio?
Hi
On 29. Sep 2021, at 15:59, Phil B pbpublist@gmail.com wrote:
A tangential FYI: the Debian packaging will be taking care of this as part of the installation.
that's what I hoped for.
Currently it installs the /etc/security/limits.d/squeak.conf file and I'll look into adding the pam.d part as well.
Noooo don't change pam_d stuff. :D Debian has now its own pam management stuff and we should not mess with it.
I was actually only curious whether tim's /etc/pam.d/* contains a reference to pam_limits, to see whether limits are applied in the first place. Since a reboot helped, the answer is, yes, pam_limits applied.
So let's not get ahead of ourselves and let pam be :)
Of course if there's a way to get the functionality without the config tweaking, that would be even better. If not, well that's one of the many reasons we have packages ;-)
Exactly.
Best regards -Tobias
On Wed, Sep 29, 2021 at 2:24 AM Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 29. Sep 2021, at 00:12, tim Rowledge tim@rowledge.org wrote:
This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
this file only takes action when pam_limits is used. can you grep your /etc/pam.d for limits?
Best regards -Tobias
PS: I hate to say it, but it seems the neat architecture of the heartbeat-VM is not appreciated by current linux distros. There is just too much to do for the average user to make use of it. Also, users need some kind of Root to be able to enable the rtprio, which is not a good idea. Is there any way to get away without changing rtprio?
Tobias,
On Wed, Sep 29, 2021 at 10:59 AM Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 29. Sep 2021, at 15:59, Phil B pbpublist@gmail.com wrote:
A tangential FYI: the Debian packaging will be taking care of this as
part of the installation.
that's what I hoped for.
You can see all of the 'global' system changes I'm making in the common package currently at https://github.com/pbella/squeak-common
Currently it installs the /etc/security/limits.d/squeak.conf file and
I'll look into adding the pam.d part as well.
Noooo don't change pam_d stuff. :D Debian has now its own pam management stuff and we should not mess with it.
Don't worry, that's why I only said I'd look into it. I won't try to slam a generic PAM config as part of the install as I know we'd need to tread carefully here.
I was actually only curious whether tim's /etc/pam.d/* contains a reference to pam_limits, to see whether limits are applied in the first place. Since a reboot helped, the answer is, yes, pam_limits applied.
So let's not get ahead of ourselves and let pam be :)
All I was thinking is that perhaps I could drop a squeak file in /etc/pam.d with any (perhaps commented out?) settings that apply to the VM along with any relevant documentation. So basically keep it non-invasive but try to provide a pointer if this is a source of potential issues. I'd also need to check Debian policy to see if this is something that should even be done as I know PAM is a touchy area re: system security and may have specific policy considerations.
Of course if there's a way to get the functionality without the config
tweaking, that would be even better. If not, well that's one of the many reasons we have packages ;-)
Exactly.
Best regards -Tobias
Thanks, Phil
On Wed, Sep 29, 2021 at 2:24 AM Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 29. Sep 2021, at 00:12, tim Rowledge tim@rowledge.org wrote:
This reminds me to ask (probably again) if anyone actually understands
ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it
appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain.
I've spent way too long trying to make sense of what I find with
googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
this file only takes action when pam_limits is used. can you grep your /etc/pam.d for limits?
Best regards -Tobias
PS: I hate to say it, but it seems the neat architecture of the
heartbeat-VM is not appreciated by
current linux distros. There is just too much to do for the averageuser to make use of it.
Also, users need some kind of Root to be able to enable the rtprio,which is not a good idea.
Is there any way to get away without changing rtprio?
Hi,
So I might be wrong about this but I don't think Squeak needs to use pam. Pam is used for authentication and authorization.
So on my linux systems there are files in /etc/pam.d with names like sshd, su, sudo and assorted login and screen saver programs.
These are all programs which have to either run something that does authorization or does authentication, or both. Squeak needs neither because we run squeak after you are logged in and the program which logged you in has taken care of the authentication and authorization. And of course setting limits.
For the users rtprio to be set to something other than the default we both need the /etc/security/limits.d/squeak.conf file, AND we need what ever is doing the "login" to call the limits shared library of pam to set the limits.
This is why the problem is complex since it is hard to know which program has done the "login"
In my test case I had to reboot the system to get the normal console login to run the new limits. Before I rebooted it did not set the rtprio from the normal console login but did set it when I used ssh to connect.
So which program and which config file is the one who does my console login? Is it login? Is it common-session? Is it light-dm? My bet is on light-dm but maybe not.
cheers
bruce
On 2021-09-29T17:28:52.000+02:00, Phil B pbpublist@gmail.com wrote:
------------------------- Tobias, On Wed, Sep 29, 2021 at 10:59 AM Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 29. Sep 2021, at 15:59, Phil B pbpublist@gmail.com wrote: A tangential FYI: the Debian packaging will be taking care of
this as part of the installation. that's what I hoped for.
You can see all of the 'global' system changes I'm making in the common package currently at https://github.com/pbella/squeak-common
Currently it installs the /etc/security/limits.d/squeak.conf
file and I'll look into adding the pam.d part as well. Noooo don't change pam_d stuff. :D Debian has now its own pam management stuff and we should not mess with it.
Don't worry, that's why I only said I'd look into it. I won't try to slam a generic PAM config as part of the install as I know we'd need to tread carefully here.
I was actually only curious whether tim's /etc/pam.d/* contains a reference to pam_limits, to see whether limits are applied in the first place. Since a reboot helped, the answer is, yes, pam_limits applied. So let's not get ahead of ourselves and let pam be :)
All I was thinking is that perhaps I could drop a squeak file in /etc/pam.d with any (perhaps commented out?) settings that apply to the VM along with any relevant documentation. So basically keep it non-invasive but try to provide a pointer if this is a source of potential issues. I'd also need to check Debian policy to see if this is something that should even be done as I know PAM is a touchy area re: system security and may have specific policy considerations.
Of course if there's a way to get the functionality without the
config tweaking, that would be even better. If not, well that's one of the many reasons we have packages ;-) Exactly. Best regards -Tobias
Thanks, Phil
On Wed, Sep 29, 2021 at 2:24 AM Tobias Pape Das.Linux@gmx.de
wrote:
Hi > On 29. Sep 2021, at 00:12, tim Rowledge tim@rowledge.org
wrote:
> > > This reminds me to ask (probably again) if anyone actually
understands ubuntu and getting the rtprio settings to 'take'.
> > I have the suggested /etc/security/limits.d/squeak.conf etc
but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain.
> I've spent way too long trying to make sense of what I find
with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
this file only takes action when pam_limits is used. can you grep your /etc/pam.d for limits? Best regards -Tobias PS: I hate to say it, but it seems the neat architecture of the
heartbeat-VM is not appreciated by
current linux distros. There is just too much to do for
the average user to make use of it.
Also, users need some kind of Root to be able to enable
the rtprio, which is not a good idea.
Is there any way to get away without changing rtprio?
Running `sudo grep limit /etc/pam.d` on my ubuntubox reveals that cron, login, runuser, sshd, su and systemd-user refer to limit.
login explicitly claims to defer to /etc/security/limits.conf runuser has the exact same line sshd ditto su ditto and finally systemd-user ditto
So they all use `session required pam_limits.so` and that claims (according to https://www.man7.org/linux/man-pages/man8/pam_limits.8.html) to read the /etc/security/limits.conf file, which in my case is nothing but comments. It also claims to then read (in C locale order, for what it's worth) the files in /etc/limits.d, including our squeak.conf file.
Despite us doing what looks like al lthe right stuff, `ulimit -a` says my realtime priority setting is 0.
To add further to the irritation, on the work server it has done the right thing and the rtprio setting is 2. Grrrrrrr. It has the same /etc/security/limits/d/squeak.conf - and indeed it works just fine on my Raspberry Pi 64bit OS.
The output of the grep above is the same.
In https://superuser.com/questions/740000/modify-and-apply-limits-conf-without-... I see a mention that the '*' part of the line doesn't apply to 'root', which... probably isn't relevant?
The potentially big difference between the local ubuntubox and the work one is that mine is 18.04.4 and the work one is 20.04
My brian hertz.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A)bort, R)etry, P)ee in drive door
So on my ubuntu 18.04.06 it works.
What do you see if once you login to your home box, try using ssh to connect to your home box again. Then what does ulimit tell you about rtprio?
cheers
bruce
On 2021-09-29T21:29:03.000+02:00, tim Rowledge tim@rowledge.org wrote:
Running `sudo grep limit /etc/pam.d` on my ubuntubox reveals that cron, login, runuser, sshd, su and systemd-user refer to limit. login explicitly claims to defer to /etc/security/limits.conf runuser has the exact same line sshd ditto su ditto and finally systemd-user ditto So they all use `session required pam_limits.so` and that claims (according to www.man7.org/linux/man-page... [https://www.man7.org/linux/man-pages/man8/pam_limits.8.html%5D)%C2%A0to%C2%A.... Despite us doing what looks like al lthe right stuff, `ulimit -a` says my realtime priority setting is 0. To add further to the irritation, on the work server it has done the right thing and the rtprio setting is 2. Grrrrrrr. It has the same /etc/security/limits/d/squeak.conf - and indeed it works just fine on my Raspberry Pi 64bit OS. The output of the grep above is the same. In superuser.com/questions/740... [https://superuser.com/questions/740000/modify-and-apply-limits-conf-without-... The potentially big difference between the local ubuntubox and the work one is that mine is 18.04.4 and the work one is 20.04 My brian hertz. tim -- tim Rowledge; tim@rowledge.org; www.rowledge.org/tim [http://www.rowledge.org/tim] A)bort, R)etry, P)ee in drive door
On 2021-09-29, at 12:44 PM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
So on my ubuntu 18.04.06 it works.
What do you see if once you login to your home box, try using ssh to connect to your home box again. Then what does ulimit tell you about rtprio?
Huh. That's interestingly weird. It works.
So what does that tell us? It isn't simply the 'login again/reboot' since the machine has been rebooted plenty of times including on Sunday after a massive-storm power outage.
The machine is set up to start and log into the default user (ie me) and GUI.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A conscience is what hurts when all your other parts feel so good.
On Tue, Sep 28, 2021 at 03:12:29PM -0700, tim Rowledge wrote:
This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
Aside from the various discussions of how to work around this problem, I would expect that the VM might better do something like this:
- Attempt to start the heartbeat thread at elevated priority. - If successful, proceed as before (other threads at normal priority) - If not successful, drop the process priority and start all other threads at a lower priority.
Note that running at lower priority does not affect performance or user experience for most users. You can verify this yourself by running Squeak at lower priority using the "nice" command, and see if you can notice any difference.
I have not looked at how to implement the above, but my expectation is that the strategy would give good results for most users, while eliminating the need for root access for first-time users installing Squeak.
Dave
On Sep 29, 2021, at 5:32 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 28, 2021 at 03:12:29PM -0700, tim Rowledge wrote:
This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
Aside from the various discussions of how to work around this problem, I would expect that the VM might better do something like this:
- Attempt to start the heartbeat thread at elevated priority.
- If successful, proceed as before (other threads at normal priority)
- If not successful, drop the process priority and start all other
threads at a lower priority.
+1. Good idea!
Note that running at lower priority does not affect performance or user experience for most users. You can verify this yourself by running Squeak at lower priority using the "nice" command, and see if you can notice any difference.
I have not looked at how to implement the above, but my expectation is that the strategy would give good results for most users, while eliminating the need for root access for first-time users installing Squeak.
Dave
On 30. Sep 2021, at 04:46, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sep 29, 2021, at 5:32 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 28, 2021 at 03:12:29PM -0700, tim Rowledge wrote:
This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
Aside from the various discussions of how to work around this problem, I would expect that the VM might better do something like this:
- Attempt to start the heartbeat thread at elevated priority.
- If successful, proceed as before (other threads at normal priority)
- If not successful, drop the process priority and start all other
threads at a lower priority.
+1. Good idea!
Right! It's obvious, in hindsight xD -t
Wow, now I feel really really old.
So nicing the priority down will be fine on a single user system - which to be honest is probably 99.9+% of our users so no problem.
It is a bad idea, though very nice, on a multi user system espeically if heavily loaded. It was always fun to nice a friend down and have them start asking why their emacs was taking 3 second per character now.
So it is probably an ok idea.
cheers
bruce
On 2021-09-30T08:11:53.000+02:00, Tobias Pape Das.Linux@gmx.de wrote:
On 30. Sep 2021, at 04:46, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sep 29, 2021, at 5:32 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 28, 2021 at 03:12:29PM -0700, tim Rowledge wrote: This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'. I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
Aside from the various discussions of how to work around this problem, I would expect that the VM might better do something like this: - Attempt to start the heartbeat thread at elevated priority. - If successful, proceed as before (other threads at normal priority) - If not successful, drop the process priority and start all other threads at a lower priority.
+1. Good idea!
Right! It's obvious, in hindsight xD -t
I'd still quite like for us to discover & document why the setting has no effect under the (relatively) normal circumstance of a machine that boots straight into a user's account and yet does work if you ssh into your own machine. That seems like a pretty dumb setup somehow.
I note that the list of /etc/pam.d file on my Pi is larger than on the ubuntubox and includes a couple that look 'suspicious' - lightdm* and vncserver.
Bruce, you mentioned that it works on your ubuntu 18 machine - what do you have for a window server? What do you have in your /etc/security & /etc/pam.d directories?
I (according to old notes that may not be reliable!) loaded http://cdimage.ubuntu.com/ubuntu/releases/18.04/release/ and chose 'Basic Ubuntu server', then added xfce4 and vncserver. I had previously tried the default Ubuntu UI but, wow, much ugly, so nasty.
tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
Windows server? We don't need no stinkin windows server.
No really, my Ubuntu 18 board has no display so I only ssh into it.
My tests on limits (requiring the reboot for the windows manager to pickup the limits file) was on an Ubuntu 20 box.
So I did not totally test your situation on Ubuntu 18. Sorry.
In terms of the vncserver file in /etc/pam.d - it is there because you added vncserver according to your notes.
Do note that there is another possibility. The installation might have had a bug in it that has never been patched.
cheers
bruce
On 2021-09-30T19:57:45.000+02:00, tim Rowledge tim@rowledge.org wrote:
I'd still quite like for us to discover & document why the setting has no effect under the (relatively) normal circumstance of a machine that boots straight into a user's account and yet does work if you ssh into your own machine. That seems like a pretty dumb setup somehow. I note that the list of /etc/pam.d file on my Pi is larger than on the ubuntubox and includes a couple that look 'suspicious' - lightdm* and vncserver. Bruce, you mentioned that it works on your ubuntu 18 machine - what do you have for a window server? What do you have in your /etc/security & /etc/pam.d directories? I (according to old notes that may not be reliable!) loaded cdimage.ubuntu.com/ubuntu/r... [http://cdimage.ubuntu.com/ubuntu/releases/18.04/release/%5D%C2%A0and%C2%A0ch.... tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
On 2021-10-01, at 5:32 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Windows server? We don't need no stinkin windows server.
No really, my Ubuntu 18 board has no display so I only ssh into it.
My tests on limits (requiring the reboot for the windows manager to pickup the limits file) was on an Ubuntu 20 box.
So I did not totally test your situation on Ubuntu 18. Sorry.
Ah, right; you effectively did the thing I did by (re)logging in with ssh.
In terms of the vncserver file in /etc/pam.d - it is there because you added vncserver according to your notes.
Oh, but the vncserver file is on my Pi and *not * on the ubuntubox. Perhaps this is the actual problem.
Do note that there is another possibility. The installation might have had a bug in it that has never been patched.
What! A bug? Surely not.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BBL: Branch on Burned out Light
On Wed, Sep 29, 2021 at 11:49 PM Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Wow, now I feel really really old.
So nicing the priority down will be fine on a single user system - which to be honest is probably 99.9+% of our users so no problem.
Remember that David is proposing lowering the priority of the threads in the process, not the process itself. It may be that thread priorities are effectively global. But it may be that they are only relative. In which case, lowering teh thread priorities may have no effect on the process's priority.
It is a bad idea, though very nice, on a multi user system espeically if heavily loaded. It was always fun to nice a friend down and have them start asking why their emacs was taking 3 second per character now.
So it is probably an ok idea.
cheers
bruce
On 2021-09-30T08:11:53.000+02:00, Tobias Pape Das.Linux@gmx.de wrote:
On 30. Sep 2021, at 04:46, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sep 29, 2021, at 5:32 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 28, 2021 at 03:12:29PM -0700, tim Rowledge wrote:
This reminds me to ask (probably again) if anyone actually understands ubuntu and getting the rtprio settings to 'take'.
I have the suggested /etc/security/limits.d/squeak.conf etc but it appears to be ignored - at least the VM complains about it. Since `ulimit -a` tells me that rtprio is 0, I suspect it is correct to complain. I've spent way too long trying to make sense of what I find with googling. This has been going on for ages (so, yes, the machine has been rebooted) and every now and then I try to make some sense of it.
Aside from the various discussions of how to work around this problem, I would expect that the VM might better do something like this:
- Attempt to start the heartbeat thread at elevated priority.
- If successful, proceed as before (other threads at normal priority)
- If not successful, drop the process priority and start all other
threads at a lower priority.
+1. Good idea!
Right! It's obvious, in hindsight xD -t
This is great news! So it's even "forward compatible" on 16.04? I will wait with the merge until the most recent upstream errors got fixed. Sigh... ☕
Merged #598 into Cog.
vm-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
David T Lewis -
David T. Lewis -
Eliot Miranda -
gettimothy -
Marcel Taeumel
-
pbella
-
Phil B -
tim Rowledge -
Tobias Pape -
Tobias Pape