cogspurlinuxht under daemontools

> 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?
>

> 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?
>
>

> 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 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 <[hidden email]> 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?
>

> 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 <[hidden email]>
>> wrote:
>>       On Sat, Jul 11, 2015 at 4:30 PM, Eliot Miranda
>> <[hidden email]> 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-daemon.
>> 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
>>
>
>
>

> 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 <[hidden email]> 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 <[hidden email]>
>>> wrote:
>>>       On Sat, Jul 11, 2015 at 4:30 PM, Eliot Miranda
>>> <[hidden email]> 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-daemon.
>>> 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.