connection failed for: localhost (Errno::EINVAL: Invalid argument - getpeername(2))

[koba]

Hello,

I managed to get Ruby, Mongrel, and Capistrano gem installed on HP-UX
11i v3 11.31 (on Itanium). Mongrel will run a Rails app... But, even
with a minimal deploy.rb, I'm getting a strange error when running a
basic Capistrano task (with only a simple 'run' helper).

My deploy.rb is simple:

set :use_sudo, false
set :application, "myapp"
role :app, "localhost"

desc "test me"
task :tester, :roles => :app do
puts "tester starting"
run "echo hello"
end

The error I'm seeing is:

$ cap tester
* executing `tester'
tester starting
* executing "echo hello"
servers: ["localhost"]
connection failed for: localhost (Errno::EINVAL: Invalid argument -
getpeername(2))

Has anyone seen this error before? I've Googled it and haven't seen
anything helpful.

I've tried setting the following to no avail:
default_run_options[:pty] = true
default_run_options[:shell] = false

I've also tried monkey patching "run" (after seeing some discussion of
problems with BASH profiles back in 2006):
def run(cmd, options={}, &block)
cmd = <<-CMD
BASH_ENV=.bashrc /usr/local/bin/bash -c -- "#{cmd}"
CMD
run_without_env cmd, options, &block
end

That didn't work either (same error in all cases).

Does anyone have any suggestions on where I might look first? I'm
running Ruby 1.8.6 and Cap v2.2.0.

Thanks,
Kyle

[Jamis Buck]

Weird, I've heard of Windows users running into that error, but even
in that case I don't know what causes it. If you figure it out, please
do report back. Sorry I can't be more helpful. :(

- Jamis

> --~--~---------~--~----~------------~-------~--~----~
> To unsubscribe from this group, send email to capistrano-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/capistrano
> -~----------~----~----~----~------~----~------~--~---
>

[koba]

Thanks for the response. I'm not looking for you to solve *all* of my
problems, so no worries. Thanks for Capistrano... it's usefulness is
the reason I'm trying to get it to run on this HP-UX box.

Right now I have a work-around, basically making serial "system" calls
in monkey-patched versions of "run" and "put" (using ssh and scp).

As for the original problem, though, I took a look at the 'net-ssh'
library to see if that would work for me. But, I ran into what looks
like the same error.

After gem-installing 'net-ssh' v1.1.2, I ran this simple test script:
require 'rubygems'
require 'net/ssh'
Net::SSH.start( 'localhost' ) do |session|
shell = session.shell.open

# script what we want to do
shell.pwd
shell.cd "/"
shell.pwd
shell.exit

# give the above commands sufficient time to terminate
sleep 0.5

# display the output
$stdout.print shell.stdout while shell.stdout?
$stderr.puts "-- stderr: --"
$stderr.print shell.stderr while shell.stderr?
end

... Which generated a very similar error...

$ ruby net.rb
/app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/lib/net/ssh/
transport/session.rb:113:in `getpeername': Invalid argument -
getpeername(2) (Errno::EINVAL)
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh/transport/session.rb:113:in `peer'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh/transport/kex/dh.rb:165:in `verify_server_key'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh/transport/kex/dh.rb:232:in `exchange_keys'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/needle-1.3.0/
lib/needle/lifecycle/proxy.rb:60:in `__send__'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/needle-1.3.0/
lib/needle/lifecycle/proxy.rb:60:in `method_missing'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh/transport/session.rb:188:in `exchange_keys'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh/transport/session.rb:149:in `kexinit'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh/transport/session.rb:107:in `initialize'
... 30 levels...
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh/session.rb:106:in `initialize'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh.rb:47:in `new'
from /app/local/ruby/1.8/lib/ruby/gems/1.8/gems/net-ssh-1.1.2/
lib/net/ssh.rb:47:in `start'
from net.rb:4

I ran this with key authentication and without (using a password).
I'm starting to think that this might have something to do with the
hacked installation of Ruby 1.8.6 I've got on this machine (which I
struggled with just to get Mongrel running).

It might have something to do with the way HP-UX places libraries in
different directories from which most installers look for them. But,
usually I resolve these when the gems crap out on installation (which
didn't happen in this case).

I'm open for suggestions on what else to try. Otherwise, I'll keep
you posted on what shakes out.

Thanks,
Kyle

>  smime.p7s
> 3KDownload

[David Masover]

On Sun, Apr 13, 2008 at 3:35 AM, koba <kyl...@gmail.com> wrote:

Hello,

I managed to get Ruby, Mongrel, and Capistrano gem installed on HP-UX
11i v3 11.31 (on Itanium).

Why Capistrano? Just curious, as I've never seen anyone try to deploy to localhost before...

$ cap tester
 * executing `tester'
tester starting
 * executing "echo hello"
   servers: ["localhost"]
connection failed for: localhost (Errno::EINVAL: Invalid argument -
getpeername(2))

Is localhost valid? That is: Can you do something like "host localhost" and get a valid reply? Does localhost have an entry in /etc/hosts?

Does it work if you specify 127.0.0.1? Or localhost.localdomain?

That's all I've got...

[koba]

Hi David,

Do you mean, why Capistrano deployments to localhost? Or, why
Capistrano on HP-UX?

I should have mentioned that 'localhost' was just for testing
purposes. I get the same error when attempting to 'run' commands on
remote machines (that I should have ssh access to). But, to be
thorough, I tried '127.0.0.1' and got the same error.

As for the question of, why Cap on HP-UX? I think a better question
is, Why HP-UX? :)

Thanks for you help.
Kyle

On Apr 14, 10:52 am, "David Masover" <d...@3mix.com> wrote:

[David Masover]

I meant why localhost, because it seems like that would be the easiest problem to eliminate -- if you can get it deploying elsewhere, but not to localhost, that's probably easier to solve than if there's some strange bug in Capistrano (or worse, Ruby) on HP-UX.

I've learned not to question peoples' OS choices unless I'm really sure they don't know any better. Religious wars really aren't helpful, as long as you realize that emacs should die and vim is the one true way!