I agree totally. We shouldn't do anything to scare away people new to Pharo. It's a hard enough sell as it is. This kind of thing only undermines my advocacy. Ben Coman wrote
On Tue, 4 Dec 2018 at 02:07, Sven Van Caekenberghe <
sven@
> wrote:
Yes, I can confirm that it looks like /etc/security/limits.d settings are not honoured inside an LXC/LXD container on Linux. I am not sure that there is a way around this, as it seems that such limits are part of the technology used to implement containers (and hence it might conflict with them by design as you could then step outside your container's limits). Maybe there is a way around this.
Note that the VM keeps on running fine, despite the warning. It feels as if that warning is a bit aggressive and that there should be an option to silence it.
Perhaps even this warning should be disabled. We've been operating a long time with the threaded-timer as default with no adverse reports. The warning undermines the confidence of new users and gets in the way of their smooth first experience.
Regarding any concern about clock jitter, perhaps the place to put this rtprio advice is in the DelayScheduler class comment, which I guess is where anyone having a problem with jitter would go looking. Here is a pertinent thread... http://forum.world.st/Unix-heartbeat-thread-vs-itimer-td4928943i20.html
cheers -ben
On 3 Dec 2018, at 17:47, Norbert Hartl <
norbert@
> wrote:
I didnât read much of this thread but the VPS might give a hint. If you
are in a virtualized server and you want to modify kernel parameters the underlying host needs to allow that.
Norbert
Am 03.12.2018 um 16:55 schrieb horrido <
horrido.hobbies@
>:
Yes, I did. I even rebooted Ubuntu.
Given that this problem occurs for both Debian and Ubuntu, there must
be
some commonality that hasn't been documented.
Ben Coman wrote
At https://linux.die.net/man/5/limits.conf I read "note that all limit settings are set per login." You haven't mentioned whether you logged out and back in again?
cheers -ben
On Mon, 3 Dec 2018 at 23:17, horrido <
horrido.hobbies@
> wrote:
I've switched over to Ubuntu Server 18.04 LTS. I've repeated all the steps to arrive at Pharo installation. I'm still having the same problem: pthread_setschedparam failed.
Here's my /etc/security/limits.d/pharo.conf:
* hard rtprio 2 * soft rtprio 2
Sven Van Caekenberghe-2 wrote
On 2 Dec 2018, at 18:40, horrido <
horrido.hobbies@
> wrote:
Bizarre. I've created a new VirtualBox image of Debian and now
this
solution no longer works! I'm still getting the thread priority warning. So this solution appears to be unreliable.
Why use Debian (not that it is bad, it is just a bit more technical) ?
I think you would have less problems using Ubuntu (it is just as open, it is what everybody else is using and it is much more user friendly).
<sigh>
On Fri, 23 Nov 2018 at 04:02, horrido <horrido.hobbies@>
wrote:
Okay, I've resolved everything. First, the reason why I'm getting
the
'pthread_setschedparam failed' error when I run Pharo under Debian is because it must be run as 'root'! Don't ask me why, but that's the reason why Pharo can't set thread priorities. (This wasn't an issue under Ubuntu Server â go figure.)
Second, I am now using Pharo's own SHA256 class. It's probably not as secure (because it doesn't use a salt value) and not as quick to execute (not being C code), but for my purpose, it doesn't really matter.
So I can use DigitalOcean or OVH to run my web server in a VPS.
Good to hear. But you shouldn't need to run Pharo as root, just be root to create this config file.... cat <
<END | sudo tee /etc/security/limits.d/pharo.conf
* hard rtprio 2
* soft rtprio 2 END
cheers -ben
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html