I have had similar experiences with rvm in production environments.

chruby (probably also rbenv, haven't used it) is easier to understand and trivial to set up with non-interactive shells.

I've had similar problems with RVM. Ultimately I used the system-wide RVM installation and this chunk of code:

  export PATH=$PATH:/usr/local/rvm/bin/rvm
  . /usr/local/rvm/scripts/rvm
  . $REPO/.rvmrc
  . $(rvm jruby-$JRUBY_VERSION do rvm env --path)
  cd $REPO
  bundle exec torquebox deploy

Definitely not ideal and I spent a large amount of hours figuring out how to use it non-interactively. I'm still somewhat worried that some things might go wrong if some of the code I didn't write in this repo attempts to call binaries directly. Basically with bundle exec --deployment, all gems are stored in $CODE/.vendor which is necessary to allow users to install their own gems, with the root installation. Bundle exec has to be used, I messed around with RVM wrappers, but they don't work with the --deployment bundler use.

You're doing too much. All you need to do is:

  source /usr/local/rvm/environments/$BUILD

You can put it in a wrapper script if you like. It will unset all conflicting environment variables first.

The thing is that the rvmrc has the jruby version env set. So I need to load it first. And it contains an 'rvm use' which I don't want to fail. I suppose I can slim the rvmrc down to just include the environment and then all I would need to do is source the rvmrc? Thoughts?

I don't believe you need to source the rvmrc. The line I pasted above does all the necessary things that "rvm use $BUILD" would do for a shell, without all the things that require an interactive shell.

The rvmrc is part of the repo and contains the java_opts env.