This shouldn't be an issue in v3 as the connections are opened afresh for each connection. When we ever build in connection caching in v3, I'll keep in mind keepalives.
Regarding that article: 1. I don’t know if Capistrano intentionally ignores the ServerAliveInterval > setting on the client machine but this one does not work. You will still > get your SSH connection terminated > I can't say, this would be Net::SSH in any case. > 2. Using the client configuration option forces you to configure each > client which deploys to have this settings. Server configuration is much > more maintainable since once you create an AMI out of the machine you will > never have to touch this setting again. This is a bit of a bad solution, as it relies on setting sane values on both sides, and it runs the risk of getting into a similar situation, if the connection is dropped, or timed out. Five minutes with Google suggests that Net:SSH doesn't support setting KeepAlive options. However it's possible to set something in ~/.ssh/config for all hosts (Host *) such as TCPKeepAlive which is almost as good. But as http://unix.stackexchange.com/a/34201 indicates there are problems. I definitely think someone should take the reigns and get keep alive implemented in Net::SSH, or at least do something with the debug log level to determine how much of this is pure conjecture, and how much might lead to a useful bug report, and possible patch. Lee Hambley -- http://lee.hambley.name/ +49 (0) 170 298 5667 On 30 July 2013 20:20, Mike Stangel <mike.stan...@myheritage.com> wrote: > There's an excellent write-up of this issue at > http://railsadventures.wordpress.com/2013/05/03/ssh-connection-closed-while-deploying-with-capistrano/ > > > On Thursday, May 12, 2011 8:17:04 AM UTC-7, Jonathan del Strother wrote: >> >> Hi, >> >> On our current servers, I keep running into problems if a particular >> channel takes longer to complete a command that its siblings. For >> example, say I have 2 servers and run a command on them simultaneously >> via capistrano. If one server finishes early, after a short period of >> inactivity (around 40 seconds?) I get : >> >> /Users/jon/.rvm/gems/ree-1.8.**7-2011.03/gems/net-ssh-2.1.4/**lib/net/ssh/ >> >> transport/session.rb:174:in `poll_message': disconnected: Timeout, >> your session not responding. (2) (Net::SSH::Disconnect) >> from /Users/jon/.rvm/gems/ree-1.8.**7-2011.03/gems/net-ssh-2.1.4/ >> **lib/ >> net/ssh/transport/session.rb:**164:in `loop' >> from /Users/jon/.rvm/gems/ree-1.8.**7-2011.03/gems/net-ssh-2.1.4/ >> **lib/ >> net/ssh/transport/session.rb:**164:in `poll_message' >> from /Users/jon/.rvm/gems/ree-1.8.**7-2011.03/gems/net-ssh-2.1.4/ >> **lib/ >> net/ssh/connection/session.rb:**451:in `dispatch_incoming_packets' >> from /Users/jon/.rvm/gems/ree-1.8.**7-2011.03/gems/net-ssh-2.1.4/ >> **lib/ >> net/ssh/connection/session.rb:**213:in `preprocess' >> from /Users/jon/.rvm/gems/ree-1.8.** >> 7-2011.03/gems/capistrano-2.6.**0/lib/ >> capistrano/processable.rb:17:**in `process_iteration' >> from /Users/jon/.rvm/gems/ree-1.8.** >> 7-2011.03/gems/capistrano-2.6.**0/lib/ >> capistrano/processable.rb:43:**in `ensure_each_session' >> from /Users/jon/.rvm/gems/ree-1.8.** >> 7-2011.03/gems/capistrano-2.6.**0/lib/ >> capistrano/processable.rb:41:**in `each' >> from /Users/jon/.rvm/gems/ree-1.8.** >> 7-2011.03/gems/capistrano-2.6.**0/lib/ >> capistrano/processable.rb:41:**in `ensure_each_session' >> from /Users/jon/.rvm/gems/ree-1.8.** >> 7-2011.03/gems/capistrano-2.6.**0/lib/ >> capistrano/processable.rb:17:**in `process_iteration' >> from /Users/jon/.rvm/gems/ree-1.8.** >> 7-2011.03/gems/capistrano-2.6.**0/lib/ >> capistrano/command.rb:165:in `process!' >> from /Users/jon/.rvm/gems/ree-1.8.** >> 7-2011.03/gems/capistrano-2.6.**0/lib/ >> capistrano/command.rb:164:in `loop' >> from /Users/jon/.rvm/gems/ree-1.8.** >> 7-2011.03/gems/capistrano-2.6.**0/lib/ >> capistrano/command.rb:164:in `process!' >> >> >> However, the ssh connection will stay alive quite happily if the >> command takes a more-or-less equal time on both servers. That is, if >> one server has a file 'foo', but the other doesn't, then running >> cap invoke COMMAND="test -f foo && sleep 60 || echo 'closing'" >> will die with the above error, as the server without 'foo' will finish >> its command early. >> >> However, an indiscriminate sleep (cap invoke COMMAND="sleep 60"), >> where all servers are stuck for the same amount of time, will >> successfully complete. >> >> >> I've seen a few mentions of this error before, but not in connection >> to this 'imbalance' of execution time between different ssh channels. >> I've tried playing with ClientAliveInterval and ClientAliveMaxCount >> without much success. I can't figure out why it dies after 40 seconds >> either, it doesn't seem related to any of the settings I've come >> across. Any other suggestions what I might try? >> >> -Jonathan > > -- > -- > * You received this message because you are subscribed to the Google > Groups "Capistrano" group. > * To post to this group, send email to capistrano@googlegroups.com > * To unsubscribe from this group, send email to > capistrano+unsubscr...@googlegroups.com For more options, visit this > group at http://groups.google.com/group/capistrano?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Capistrano" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to capistrano+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to capistrano@googlegroups.com * To unsubscribe from this group, send email to capistrano+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en --- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
