sandro / specjour

distributed rspec & cucumber via bonjour
MIT License
212 stars 33 forks source link

second invocation of "rake specjour" fails #16

Closed jfrankov closed 14 years ago

jfrankov commented 14 years ago

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
sandro commented 14 years ago

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)
sandro commented 14 years ago

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

jfrankov commented 14 years ago

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]]
sandro commented 14 years ago

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

jfrankov commented 14 years ago

$ /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
sandro commented 14 years ago

DRb connects via hostname if IP can't be resolved

Closed by 217c2c4ad37984a1b09e4947fdac61b4225e64cf Closed by 217c2c4ad37984a1b09e4947fdac61b4225e64cf