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