Hi Chris,

I really know very little about this. I don't understand the mechanism. But I'm told that the limits file takes effect on login. i.e. if the file is created while a user is logged in it won't take effect for that user until that user logs out and logs back in again and only applies to those sessions that logged in once the file had been created. I /dont/ know whether su sets up a new session. i should try that experiment.

So perhaps you could have daemon tools run login or su to create a new session and see if the ht version can be run by daemontools in that session. Presumably daemons launched at boot aren't in the right state. (What an absurdity they've invented here).

Eliot (phone)

On Jul 11, 2015, at 1:23 PM, Chris Muller asqueaker@gmail.com wrote:

Hi Levente, I'm still having the same trouble with this even after rebooting the server. I'd like to be able to run with the "HT" VM, but I think I may be wasting my time because its not possible at all [1]. Maybe there's a way around that, I don't know..

Which is why I'd like to ask: Can you confirm that you have or are successfully running the HT vm when the effective UID of the process does not match the UID of the user that invoked it (as when daemontools, running under root, would use "setuidgid" to run the VM)?

Thanks.

[1] The manpage referred to earlier says: "Subject to the same rules, another unprivileged process can also make these changes, as long as the effective user ID of the process making the change matches the real or effective user ID of the target process."

On Fri, Jun 19, 2015 at 8:16 AM, Levente Uzonyi leves@elte.hu wrote:

...

Try restarting the daemontools daemon. Changes to the limits affect only the processes started after the change.

Levente

On Thu, 18 Jun 2015, Chris Muller wrote:

...

I am having trouble using the "HT" version of the Spur VM under daemontools. When the daemon attempts to launch the image it gets the familiar pthread error:

pthread_setschedparam failed: Operation not permitted Read e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r3370/README.3370

however, I *definitely* have my /etc/security/limits.d/squeak.conf file set up as instructed (been working fine for ages), and in fact I'm able to run the same image with the same startup script under the same uidgid manually. (e.g., I'm able to cut-n-paste the line from my "run" script into the terminal and it works fine...)

exec setuidgid magma /usr/local/bin/spur -vm display=none server-spur.image $DIR/run.st `cat port`

... but when daemontools runs it, gets the pthread error. Weird! Any ideas?

Hi Chris,

On Wed, Jul 15, 2015 at 9:17 AM, Chris Muller ma.chris.m@gmail.com wrote:

On Sat, Jul 11, 2015 at 4:30 PM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Hi Chris,

I really know very little about this.  I don't understand the

mechanism. But I'm told that the limits file takes effect on login. i.e. if the file is created while a user is logged in it won't take effect for that user until that user logs out and logs back in again and only applies to those sessions that logged in once the file had been created. I /dont/ know whether su sets up a new session. i should try that experiment.

...

So perhaps you could have daemon tools run login or su to create a new

session and see if the ht version can be run by daemontools in that session. Presumably daemons launched at boot aren't in the right state. (What an absurdity they've invented here).

Good suggestion to try, unfortunately it didn't work. I tried logging in as root to see if it would "initialize" that account to have those permissions, then logging out and starting the daemon. Same error.

See http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daem.... Apparently

"At this time, you can't. limits.conf(5) is the configuration for pam_limits(8), which is activated by the PAM stack according to the configuration in /etc/pam.d. However, start-stop-daemon(8) as launched from an init.d script doesn't pass through the PAM stack, so those kinds of settings are never applied.

Debian bug #302079 https://bugs.debian.org/302079 contains a patch to enable setting limits from start-stop-daemon(8), but the bug has been open since 2005 and the patch hasn't been merged yet. While not ideal, AFAIK the recommended way to accomplish this right now is to add a ulimitcall in your init.d script."

Looks like this is settable via ulimit -r; From man ulimit(1) (actually from bash (1)) -r The maximum real-time scheduling priority

Of course this may not work:

ulimit -r 3 $ -bash: ulimit: real-time priority: cannot modify limit: Operation not permitted

But it's worth a try.

For the sake of progress, I've switched to using the ITHB vm.

Chris,

can you confirm? If it does, I'll add it to the relevant readmes.

On Thu, Jul 16, 2015 at 11:39 AM, Levente Uzonyi leves@elte.hu wrote:

This should work, because the daemontools start script is executed by root. I assume that it's enough to the highest priority to 2, so the following should work:

ulimit -r 2 exec setuidgid <account> <ht_vm_executable> <image> ...

Levente

On Wed, 15 Jul 2015, Eliot Miranda wrote:

Hi Chris,

...

On Wed, Jul 15, 2015 at 9:17 AM, Chris Muller ma.chris.m@gmail.com wrote: On Sat, Jul 11, 2015 at 4:30 PM, Eliot Miranda < eliot.miranda@gmail.com> wrote: > Hi Chris, > > I really know very little about this. I don't understand the mechanism. But I'm told that the limits file takes effect on login. i.e. if the file is created while a user is logged in it won't take effect for that user until that user logs out and logs back in again and only applies to those sessions that logged in once the file had been created. I /dont/ know whether su sets up a new session. i should try that experiment. > > So perhaps you could have daemon tools run login or su to create a new session and see if the ht version can be run by daemontools in that session. Presumably daemons launched at boot aren't in the right state. (What an absurdity they've invented here).

  Good suggestion to try, unfortunately it didn't work.  I tried

logging in as root to see if it would "initialize" that account to have those permissions, then logging out and starting the daemon. Same error.

See http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daem.... Apparently

"At this time, you can't. limits.conf(5) is the configuration for pam_limits(8), which is activated by the PAM stack according to the configuration in /etc/pam.d. However, start-stop-daemon(8) as launched from an init.d script doesn't pass through the PAM stack, so those kinds of settings are never applied.

Debian bug #302079 contains a patch to enable setting limits from start-stop-daemon(8), but the bug has been open since 2005 and the patch hasn't been merged yet.

While not ideal, AFAIK the recommended way to accomplish this right now is to add a ulimitcall in your init.d script."

Looks like this is settable via ulimit -r; From man ulimit(1) (actually from bash (1)) -r The maximum real-time scheduling priority

Of course this may not work:

ulimit -r 3$ -bash: ulimit: real-time priority: cannot modify limit: Operation not permitted

But it's worth a try.

  For the sake of progress, I've switched to using the ITHB vm.

-- best,Eliot

The following works on my machine (Ubuntu 14.04):

#!/bin/bash

cd /path/to/squeak/directory ulimit -r 2 exec setuidgid <account> ./coglinuxht/squeak -vm display-null -vm sound-null squeak.image

Note that ulimit requires bash, so using #!/bin/bash is a must.

Levente

On Thu, 16 Jul 2015, Chris Muller wrote:

It says:

@4000000055a8092e00454854 ./run: 7: ulimit: Illegal option -r

I'm using Ubuntu 14.04LTS 64-bit server edition. It has no man page for ulimit but my own Ubuntu 12.04 on my laptop does. It said args to that are UL_GETFSIZE and UL_SETFSIZE. So I tried adding

ulimit UL_SETFSIZE 2

before my exec but it said:

@4000000055a80a732330e364 ./run: 7: ulimit: too many arguments

This is not a huge deal since the ITHB vm works, I just thought you might have already succeeded with HT and "knew the trick" to it..

On Thu, Jul 16, 2015 at 1:39 PM, Levente Uzonyi leves@elte.hu wrote:

...

This should work, because the daemontools start script is executed by root. I assume that it's enough to the highest priority to 2, so the following should work:

ulimit -r 2 exec setuidgid <account> <ht_vm_executable> <image> ...

Levente

On Wed, 15 Jul 2015, Eliot Miranda wrote:

...

Hi Chris, On Wed, Jul 15, 2015 at 9:17 AM, Chris Muller ma.chris.m@gmail.com wrote: On Sat, Jul 11, 2015 at 4:30 PM, Eliot Miranda eliot.miranda@gmail.com wrote: > Hi Chris, > > I really know very little about this. I don't understand the mechanism. But I'm told that the limits file takes effect on login. i.e. if the file is created while a user is logged in it won't take effect for that user until that user logs out and logs back in again and only applies to those sessions that logged in once the file had been created. I /dont/ know whether su sets up a new session. i should try that experiment. > > So perhaps you could have daemon tools run login or su to create a new session and see if the ht version can be run by daemontools in that session. Presumably daemons launched at boot aren't in the right state. (What an absurdity they've invented here).

  Good suggestion to try, unfortunately it didn't work.  I tried

logging in as root to see if it would "initialize" that account to have those permissions, then logging out and starting the daemon. Same error.

See http://superuser.com/questions/454465/make-ulimits-work-with-start-stop-daem.... Apparently

"At this time, you can't. limits.conf(5) is the configuration for pam_limits(8), which is activated by the PAM stack according to the configuration in /etc/pam.d. However, start-stop-daemon(8) as launched from an init.d script doesn't pass through the PAM stack, so those kinds of settings are never applied.

Debian bug #302079 contains a patch to enable setting limits from start-stop-daemon(8), but the bug has been open since 2005 and the patch hasn't been merged yet.

While not ideal, AFAIK the recommended way to accomplish this right now is to add a ulimitcall in your init.d script."

Looks like this is settable via ulimit -r; From man ulimit(1) (actually from bash (1)) -r The maximum real-time scheduling priority

Of course this may not work:

ulimit -r 3$ -bash: ulimit: real-time priority: cannot modify limit: Operation not permitted

But it's worth a try.

  For the sake of progress, I've switched to using the ITHB vm.

-- best,Eliot