second invocation of "rake specjour" fails #16

Closed
jfrankov opened this Issue Oct 7, 2010 · 6 comments

Comments

Projects
None yet
2 participants

jfrankov commented Oct 7, 2010

The first time I run rake specjour, it works fine. I can break out of it with ctrl-c. If I try to run it again, I get this:

$ rake specjour
(in /Users/cto/git/myproj)
Waiting for managers
Managers found: 0

...and it exits. If I close the shell, open a new one and run it again, I get this new error:

$  rake specjour --trace
(in /Users/cto/git/myproj)
** Invoke specjour (first_time)
** Invoke specjour:dispatch (first_time)
** Execute specjour:dispatch
Waiting for managers
rake aborted!
getaddrinfo: nodename nor servname provided, or not known
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/socket_helpers.rb:4:in `getaddrinfo'
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/socket_helpers.rb:4:in `ip_from_hostname'
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/dispatcher.rb:97:in `resolve_reply'
/Library/Ruby/Gems/1.8/gems/dnssd-1.3.1/lib/dnssd/service.rb:160:in `process'
/Library/Ruby/Gems/1.8/gems/dnssd-1.3.1/lib/dnssd/service.rb:254:in `resolve'
/Library/Ruby/Gems/1.8/gems/dnssd-1.3.1/lib/dnssd.rb:178:in `send'
/Library/Ruby/Gems/1.8/gems/dnssd-1.3.1/lib/dnssd.rb:178:in `run'
/Library/Ruby/Gems/1.8/gems/dnssd-1.3.1/lib/dnssd.rb:170:in `resolve!'
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/dispatcher.rb:96:in `resolve_reply'
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/dispatcher.rb:70:in `gather_managers'
/Library/Ruby/Gems/1.8/gems/dnssd-1.3.1/lib/dnssd/service.rb:160:in `process'
/Library/Ruby/Gems/1.8/gems/dnssd-1.3.1/lib/dnssd/service.rb:65:in `browse'
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/dispatcher.rb:68:in `gather_managers'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/timeout.rb:62:in `timeout'
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/dispatcher.rb:67:in `gather_managers'
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/dispatcher.rb:24:in `start'
/Library/Ruby/Gems/1.8/gems/specjour-0.2.5/lib/specjour/tasks/dispatch.rake:6
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:597:in `invoke_with_call_chain'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:607:in `invoke_prerequisites'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:604:in `each'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:604:in `invoke_prerequisites'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:596:in `invoke_with_call_chain'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `each'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Users/cto/.gem/ruby/1.8/gems/rake-0.8.7/bin/rake:31
/usr/bin/rake:19:in `load'
/usr/bin/rake:19
Owner

sandro commented Oct 7, 2010

I think these are two separate issues. When you break out of specjour with ctrl-c the workers interpret that as a lost connection and spend a few (2-5, I don't remember) seconds trying to reconnect. So if you ctrl-c and re-run specjour immediately afterwards you won't find any managers because the manager is waiting for its workers to shut down.

I believe the getaddrinfo exception is raised when bonjour isn't available on your network...I have limited experience with this bug. Can you run this in irb and post back?

require 'socket'
Socket.getaddrinfo(Socket.gethostname, nil, Socket::AF_INET, Socket::SOCK_STREAM)
Owner

sandro commented Oct 7, 2010

Also, the latest development and gem pre-release is based on the thor branch. It shouldn't fix the getaddrinfo problem but ctrl-c is handled a little better. http://github.com/sandro/specjour/tree/thor

Thanks for the reply. Here's the irb output:

irb(main):001:0> require 'socket'
=> true
irb(main):002:0> Socket.getaddrinfo(Socket.gethostname, nil, Socket::AF_INET, Socket::SOCK_STREAM)
=> [["AF_INET", 0, "10.0.0.4", "10.0.0.4", 2, 1, 6], ["AF_INET", 0, "10.211.55.2", "10.211.55.2", 2, 1, 6], ["AF_INET", 0, "10.37.129.2", "10.37.129.2", 2, 1, 6]]
Owner

sandro commented Oct 13, 2010

How do those ip addresses map to your network interfaces? Paste your ifconfig.

$ /sbin/ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
inet6 fda3:cfa4:9a05:2e3:c62c:3ff:fe0d:78ed prefixlen 128

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

stf0: flags=0<> mtu 1280

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether c4:2c:03:0d:78:ed 
media: autoselect
status: inactive

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether f8:1e:df:f1:90:31 
inet6 fe80::fa1e:dfff:fef1:9031%en1 prefixlen 64 scopeid 0x5 
inet 10.0.0.6 netmask 0xffffff00 broadcast 10.0.0.255
media: <unknown subtype>
status: active

fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
lladdr e8:06:88:ff:fe:f4:46:fe 
media: autoselect <full-duplex>
status: inactive

vnic0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:1c:42:00:00:08 
inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255
media: autoselect
status: active

vnic1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:1c:42:00:00:09 
inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255
media: autoselect
status: active
Owner

sandro commented Nov 1, 2010

DRb connects via hostname if IP can't be resolved

Closed by 217c2c4
Closed by 217c2c4

indirect referenced this issue in elcuervo/airplay Oct 31, 2013

Closed

SocketError #46

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment