Capistrano just hangs.
Todd Vierheller
Both the deployment server and the target servers (application on one,
DB on the other) that work are running openSuSE on a 32 bit processor.
The servers that I cannot deploy to are running Enterprise SuSE 10.1
on a 64 bit machine. I can deploy manually (checkout) on the servers
that do not work with Capistrano. All machines have the same root
password. I serve subversion using Apache from an openSuSE machine
with a 32 bit processor. All machines are virtual Zen machines.
# cap deploy
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
* executing "/usr/local/bin/svn checkout -q -r2180
http://192.168.19.120/svncode/harmony/integration/20071119-2180
/var/www/harmony_uat/releases/20071120002453 && (echo 2180 >
/var/www/harmony_uat/releases/20071120002453/REVISION)"
servers: ["192.168.0.164", "192.168.0.166"]
Password:
[192.168.0.164] executing command
[192.168.0.166] executing command
** [out] Authentication realm: <http://192.168.19.120:80> Subversion repository
** [out] Password for 'root':
** [out]
** [out] Authentication realm: <http://192.168.19.120:80> Subversion repository
** [out] Username:
Capistrano just hangs here. After I hit CTRL-C the trace appears:
*** [deploy:update_code] rolling back
* executing "rm -rf /var/www/harmony_uat/releases/20071120002453; true"
servers: ["192.168.0.164", "192.168.0.166"]
[192.168.0.164] executing command
[192.168.0.166] executing command
command finished
/usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/command.rb:49:in
`sleep': Interrupt
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/command.rb:49:in
`process!'
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/command.rb:36:in
`loop'
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/command.rb:36:in
`process!'
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/command.rb:11:in
`process'
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/configuration/actions/invocation.rb:52:in
`run'
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/configuration/connections.rb:135:in
`execute_on_servers'
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/configuration/actions/invocation.rb:50:in
`run'
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/recipes/deploy/strategy/base.rb:43:in
`send'
... 31 levels...
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/lib/capistrano/cli/execute.rb:14:in
`execute'
from /usr/local/lib/ruby/gems/1.8/gems/capistrano-2.0.0/bin/cap:4
from /usr/local/bin/cap:16:in `load'
from /usr/local/bin/cap:16
If I run a cap deploy:check, everything is a "go":
# cap deploy:check
* executing `deploy:check'
* executing "test -d /var/www/harmony_uat/releases"
servers: ["192.168.0.164", "192.168.0.166"]
Password:
[192.168.0.164] executing command
[192.168.0.166] executing command
command finished
* executing "test -w /var/www/harmony_uat"
servers: ["192.168.0.164", "192.168.0.166"]
[192.168.0.164] executing command
[192.168.0.166] executing command
command finished
* executing "test -w /var/www/harmony_uat/releases"
servers: ["192.168.0.164", "192.168.0.166"]
[192.168.0.164] executing command
[192.168.0.166] executing command
command finished
* executing "which /usr/local/bin/svn"
servers: ["192.168.0.164", "192.168.0.166"]
[192.168.0.164] executing command
[192.168.0.166] executing command
command finished
You appear to have all necessary dependencies installed
I'd appreciate any suggestions.
NOTE: Server IP addresses have been modified for this posting.
kent.l...@gmail.com
using Cap2.1 for a while just fine. Very strange since I didn't
update anything except making a new SVN branch on the same server that
was working fine before. As of right now, I'm still not able to
deploy. The only difference for me is that we're using HTTPS instead
of the HTTP in your example. Whenever this came up before I just had
to prime the servers w/ a local checkout as the deploy user on the
server to pick up the credentials but that's not working this time.
I also just posted about this in a diff. thread.
http://groups.google.com/group/capistrano/browse_thread/thread/3aaea7539223f8a2
I'm hoping it's just something silly.
Thanks...
On Nov 20, 7:32 am, "Todd Vierheller" <azto...@gmail.com> wrote:
> I can deploy successfully to one set of servers, but not the other.
> Both the deployment server and the target servers (application on one,
> DB on the other) that work are running openSuSE on a 32 bit processor.
> The servers that I cannot deploy to are running Enterprise SuSE 10.1
> on a 64 bit machine. I can deploy manually (checkout) on the servers
> that do not work with Capistrano. All machines have the same root
> password. I serve subversion using Apache from an openSuSE machine
> with a 32 bit processor. All machines are virtual Zen machines.
>
> # cap deploy
> * executing `deploy'
> * executing `deploy:update'
> ** transaction: start
> * executing `deploy:update_code'
kent.l...@gmail.com
slash on my repo name.
http://groups.google.com/group/capistrano/browse_thread/thread/4b199f3d30b6208
> Both the deployment server and the target servers (application on one,
> DB on the other) that work are running openSuSE on a 32 bit processor.
> The servers that I cannot deploy to are running Enterprise SuSE 10.1
> on a 64 bit machine. I can deploy manually (checkout) on the servers
> that do not work with Capistrano. All machines have the same root
> password. I serve subversion using Apache from an openSuSE machine
> with a 32 bit processor. All machines are virtual Zen machines.
>
> # cap deploy
> * executing `deploy'
> * executing `deploy:update'
> ** transaction: start
> * executing `deploy:update_code'