Strange Capistrano deploy error - executing environment.rb?


#1

Capistrano 1.4
Source system: Win XP
Target system: Red Hat 10.x

BACKGROUND:
I recently added the following to my environment.rb file in order to use
the Ruby-Java bridge (RJB):

require ‘rjb’
gem ‘rjb’, ‘>= 1.0.3’
Rjb::load("#{RAILS_ROOT}/lib/jxl.jar", [’-Xmx512M’])

PROBLEM:
When I deploy to my remote system, when this line in deploy.rb:

run “cd #{current_path}; rake db:migrate RAILS_ENV=test;”

is executed, I see the following in the log:

executing “cd ~dusan/eSimplyTest/current; rake db:migrate
RAILS_ENV=test;”
servers: [“192.168.1.102”]
[192.168.1.102] executing command
** [out :: 192.168.1.102] /usr/bin/rake:17:Warning: require_gem is
obsolete. Use gem instead.
** [out :: 192.168.1.102] (in
/home/dusan/eSimplyTest/releases/20070219185329)
** [out :: 192.168.1.102] rake aborted!
** [out :: 192.168.1.102] can’t create Java VM
** [out :: 192.168.1.102]
** [out :: 192.168.1.102] (See full trace by running task with --trace)

Notice the “can’t create Java VM” line, as though it’s attempting to run
the code in environment.rb. I’ve verified that this is the problem by
commenting out the Jrb setup lines in environment.rb and redeploying and
not seeing the error anymore.

What’s going on here? Why is a rake db:migrate command attempting to
run environment.rb?

If I run “cd ~dusan/eSimplyTest/current; rake db:migrate
RAILS_ENV=test;” on the target server by hand as the correct user, I
don’t see any mention of Java VM, and the migrate proceeeds normally.
Also, if I run a SSH session from my Windows box to the target server
and issue this command, it works fine - I don’t see this error.

Does anyone understand why stuff in my environment.rb is affecting my
deployment with Capistrano in this way?

Any insight is appreciated.

Thanks,
Wes


#2

As it turns out, this is due to the fact that the ssh calls do not
execute the regular login script for the user on the remote host.

Adding some statements to set environment variables to allow Java stuff
to work did the trick.

Thanks,
Wes