second invocation of "rake specjour" fails
jfrankov opened this issue · 6 comments
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
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)
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]]
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