And I'm especially glad to hear that it wasn't a problem with capistrano. :)
- Jamis On Oct 17, 2007, at 12:46 PM, Aleksey Gureiev wrote:
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 stuckwith the second. Again I'm not sure if it even needs the second, truthbe 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?- AlekseyOn 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 (usingssh_options[:verbose]=:debug) and email it to me direct, I'll try andlook at it today.- JamisOn 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 onetime 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 tobe 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.- AlekseyOn Oct 17, 5:39 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:Please try adding this to your deploy.rb:default_run_options[:pty] = trueI'm going to be releasing an update to cap that makes this the default.- JamisOn 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 3KDownloadsmime.p7s 3KDownloadsmime.p7s 3KDownload--~--~---------~--~----~------------~-------~--~----~To unsubscribe from this group, send email to capistrano- [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/ group/capistrano-~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
