Hi all,
After isolating the problem with the following one-liner in bash:
$ /usr/local/rvm/bin/rvm default exec ruby -e 'puts
IO.for_fd(3).inspect' 3<<<test
#<IO:fd 3>
$ bundle exec ruby -e 'puts IO.for_fd(3).inspect' 3<<<test
-e:1:in `for_fd': The given fd is not accessible because RubyVM reserves
it (ArgumentError)
from -e:1:in `<main>'
$ /usr/local/rvm/rubies/default/bin/ruby -r bundler/setup -e 'puts
IO.for_fd(3).inspect' 3<<<test
#<IO:fd 3>
It became obvious that RVM is not to blame, and the real culprit was
Bundler’s `bundle exec` script. From here it was just a matter of
figuring out how to launch the unicorn script from within the bundle
using the correct ruby without calling `bundle exec`. There are a
number of ways to do that, here is what worked for me:
ExecStart = /usr/local/rvm/gems/ruby-2.0.0-p645/wrappers/ruby -r
bundler/setup vendor/bundle/ruby/2.0.0/bin/unicorn -c
config/unicorn/unicorn.rb -E staging -s myapp@%i
Thanks again to all participants, your input was invaluable.
P.S. Notice how I abuse the -s no-op parameter to identify which
template instance is running in systemd (in the output of ps, for
example), maybe worth documenting it as a feature?
Regards,
Amir
