Jamis,
My sincere apologies. It's stupid me. For some reason it worked on
Windows, but it really hung on Linux -- there was an non-obvious
mistake in the name of the site in the roles configuration. I
carefully substituted the real name posting my configs here and it
became impossible to detect. There was 'I' (capital 'i') instead of
'l' (small 'l') in the name of the server. Argh... _ happens, as they
say.
I went all the way down to TCPSocket.open(...) in SSH/Trasport that
never returned and realized that it's better to look better. I
replaced the names with IPs. It worked. Then put the names back by
typing them, instead of undo, and it continued to work. Comparing
files against SVN versions showed the problem.
Sorry for your time and thanks for incredible tools!
Aleksey
On Oct 17, 8:14 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> Wierd...I have no idea why it is trying to connect to site.com twice.
> Would you mind posting your role declarations?
>
> - Jamis
>
> On Oct 17, 2007, at 10:45 AM, Aleksey Gureiev wrote:
>
>
>
> > Jamis,
>
> > Let me update you quickly... (btw, kudos for writing all this
> > brilliance yourself -- just discovered that net/ssh is also your
> > child!)
>
> > Back to business... As you may notice my servers array looks like
> > this:
>
> > ["site.com", "site.com"]
>
> > I'm not positive if it's correct, but the configuration looks right
> > and actually it's not the point. The point is that I modified lib/
> > capistrano/ssh.rb with some trace code a bit, like this:
>
> > ---
>
> > puts 'connecting: ' + server.host.to_s + ' options: ' +
> > connection_options.inspect
> > connection = Net::SSH.start(server.host, connection_options,
> > &block)
> > puts 'connected'
> > Server.apply_to(connection, server)
> > puts 'server applied'
>
> > ---
>
> > ... and here's what I can see now:
>
> > ---
> > [EMAIL PROTECTED]:~/projects/rails/swh/trunk$ cap deploy:check
> > * executing `deploy:check'
> > * executing "test -d /u/site/tools/swh/releases"
> > servers: ["site.com", "site.com"]
> > synchronous_connect: true
> > connecting: site.com options:
> > {:password=>nil, :port=>31313, :username=>nil, :auth_methods=>
> > ["publickey",
> > "hostbased"]}
> > connected
> > server applied
> > connecting: site.com options:
> > {:password=>nil, :port=>31313, :username=>nil, :auth_methods=>
> > ["publickey",
> > "hostbased"]}
> > ---
>
> > (oh yes, and I enabled "synchronous_connect" to see it in a sequence)
>
> > You can see that it established the first connection and then stuck
> > with the second. Again I'm not sure if it even needs the second, truth
> > be told, but anyway.
>
> > I also wrote a quick test for Net::SSH and it succeeds with a single
> > connection, which is quite inspiring. :)
>
> > Do you still need the verbose dump, or maybe I induced some ideas?
>
> > - Aleksey
>
> > On Oct 17, 7:32 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> >> Interesting, it is hanging on the connect, not on the execute. I'm
> >> pretty hammered, time-wise, but if you'll do a ssh dump (using
> >> ssh_options[:verbose]=:debug) and email it to me direct, I'll try and
> >> look at it today.
>
> >> - Jamis
>
> >> On Oct 17, 2007, at 9:54 AM, Aleksey Gureiev wrote:
>
> >>> Jamis,
>
> >>> Tried. No luck. It still hangs without anything going on.
>
> >>> tcpdump shows enormous activity right before this and then...
> >>> everything dies out and I can see my PC pinging server with some
> >>> packets (odd packet numbers) every 45 seconds without any server
> >>> responses. I can provide a detailed debug info of the session
> >>> (ssh_options[:verbose]=:debug or raw tcpdump output if you like).
>
> >>> Also, in case if it helps. Here's the stack trace I get when
> >>> interrupt
> >>> the endless waiting (btw, it may not be endless actually. I think
> >>> one
> >>> time I saw a connection timeout error, but it may be a wrong way to
> >>> go). From the sources, it looks like it's waiting for all servers to
> >>> be connected (threads.each { |t| t.join }). Not sure if it helps:
>
> >>> -----
> >>> /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/capistrano/
> >>> configuration/connections.rb:87:in `join': Interrupt
> >>> from /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/
> >>> capistrano/configuration/connections.rb:87:in
> >>> `establish_connections_to'
> >>> from /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/
> >>> capistrano/configuration/connections.rb:87:in `each'
> >>> from /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/
> >>> capistrano/configuration/connections.rb:87:in
> >>> `establish_connections_to'
> >>> from /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/
> >>> capistrano/configuration/connections.rb:125:in `execute_on_servers'
> >>> from /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/
> >>> capistrano/configuration/actions/invocation.rb:51:in `run'
> >>> from /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/
> >>> capistrano/recipes/deploy/remote_dependency.rb:86:in `try'
> >>> from /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/
> >>> capistrano/recipes/deploy/remote_dependency.rb:14:in `directory'
> >>> from /usr/lib/ruby/gems/1.8/gems/capistrano-2.1.0/lib/
> >>> capistrano/recipes/deploy/strategy/base.rb:31:in `check!'
> >>> -----
>
> >>> Thanks for your efforts, guys! I'm not going to give up even if I
> >>> will
> >>> need to debug the thing. So please bombard me with ideas and I'll
> >>> provide any details necessary to nail it.
>
> >>> - Aleksey
>
> >>> On Oct 17, 5:39 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> >>>> Please try adding this to your deploy.rb:
>
> >>>> default_run_options[:pty] = true
>
> >>>> I'm going to be releasing an update to cap that makes this the
> >>>> default.
>
> >>>> - Jamis
>
> >>>> On Oct 17, 2007, at 8:14 AM, Mislav Marohnić wrote:
>
> >>>>> On 10/17/07, Aleksey Gureiev <[EMAIL PROTECTED]> wrote:
>
> >>>>> No luck. Why should it work, btw? It uses the same means of
> >>>>> connecting
> >>>>> to the server. Hangs here:
>
> >>>>> [EMAIL PROTECTED]:~/projects/rails/swh/trunk$ cap deploy:check
> >>>>> * executing `deploy:check'
> >>>>> * executing "test -d /u/site/tools/swh/releases"
> >>>>> servers: ["site.com", "site.com"]
>
> >>>>> Then there's a possibility it is local, yeah. Can you gem update
> >>>>> capistrano and try again?
>
> >>>> smime.p7s
> >>>> 3KDownload
>
> >> smime.p7s
> >> 3KDownload
>
> > >
>
>
> smime.p7s
> 3KDownload
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
