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 at gmail.com> wrote:
>       On Sat, Jul 11, 2015 at 4:30 PM, Eliot Miranda <eliot.miranda at 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-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
> 
>