Problem running ./all-bash on mac os x leopard
kc
--- FAIL: http.TestClient
Get http://www.google.com/robots.txt: dial tcp www.google.com:http:
lookup www.google.com. on 10.0.1.1:53: no answer from server
--- FAIL: http.TestRedirect
Get http://codesearch.google.com/: dial tcp
codesearch.google.com:http: lookup codesearch.google.com. on
10.0.1.1:53: no answer from server
FAIL
make[1]: *** [test] Error 1
make: *** [http.test] Error 2
What could be causing the http.TestClient to fail? I verified that I
am connected and able to browser to www.google.com and
codesearch.google.com.
Russ Cox
>
> While running ./all.bash, I got this error:
>
> --- FAIL: http.TestClient
> Get http://www.google.com/robots.txt: dial tcp www.google.com:http:
> lookup www.google.com. on 10.0.1.1:53: no answer from server
> --- FAIL: http.TestRedirect
> Get http://codesearch.google.com/: dial tcp
> codesearch.google.com:http: lookup codesearch.google.com. on
> 10.0.1.1:53: no answer from server
> FAIL
> make[1]: *** [test] Error 1
> make: *** [http.test] Error 2
Typically this happens because you are offline or because
your firewall is blocking the DNS packets from coming back.
At this point in the build process you've built everything,
so if you don't care about the network tests you can just
move on to actually using the system.
In particular, on a Mac if you have the firewall enabled
it won't let programs listen on UDP sockets, which the
Go DNS resolver needs to do. But it could just as easily
be some other piece of your network.
Russ
Sverre Rabbelier
On Wed, Nov 11, 2009 at 10:03, kc <kec...@gmail.com> wrote:
> What could be causing the http.TestClient to fail? I verified that I
> am connected and able to browser to www.google.com and
> codesearch.google.com.
From other posts to the mailing list there's probably a firewall in
the way, have a look through the list archives for a more detailed
explanation.
--
Cheers,
Sverre Rabbelier
kc
incoming
connection from these hosts. I think there may be
a bug in mac os firewall?? it prompts me to say Allow or Deny
in a popup. I always clicked Allow. Security > firewall also says
Allow.
But I had to check "Allow all incoming connections", then it's all
happy.
I hope it doesnt want all my ports open all the time while Go'ing.
=).
I am going to set my firewall back
Any insight?
On Nov 11, 1:03 am, kc <kec...@gmail.com> wrote:
> While running ./all.bash, I got this error:
>
> --- FAIL: http.TestClient
> Gethttp://www.google.com/robots.txt:dial tcpwww.google.com:http:
> --- FAIL: http.TestRedirect
> Gethttp://codesearch.google.com/:dial tcp
Jens Alfke
On Nov 11, 2009, at 1:09 AM, Russ Cox wrote:
> In particular, on a Mac if you have the firewall enabled
> it won't let programs listen on UDP sockets, which the
> Go DNS resolver needs to do.
Does Go really need to run its own DNS resolver? Every OS already provides one built-in. Even if Go's is better in some way, it's going to be handicapped by needing to open a UDP listener port (which I think will be problematic on the future in Windows too, as well as Mac OS), as well as not sharing a DNS cache with other processes.
Perhaps the custom DNS could be included as an opt-in option for programs that really want its extra features(?), but the library defaults to using the OS's DNS.
—Jens
John Cowan
>
>
> On Nov 11, 2009, at 1:09 AM, Russ Cox wrote:
>
>> In particular, on a Mac if you have the firewall enabled
>> it won't let programs listen on UDP sockets, which the
>> Go DNS resolver needs to do.
>
> Does Go really need to run its own DNS resolver? Every OS already provides one built-in.
Unfortunately, they are neither re-entrant nor thread-safe. Since
goroutines are green threads, the whole app would be frozen if any one
goroutine did a DNS lookup.
> Even if Go's is better in some way, it's going to be handicapped by needing to open a UDP listener port (which I think will be problematic on the future in Windows too, as well as Mac OS), as well as not sharing a DNS cache with other processes.
Caching is done by DNS servers, not by DNS client libraries.
>
> Perhaps the custom DNS could be included as an opt-in option for programs that really want its extra features(?), but the library defaults to using the OS's DNS.
>
> —Jens
--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures
Jens Alfke
On Nov 11, 2009, at 9:42 AM, John Cowan wrote:
>> Does Go really need to run its own DNS resolver? Every OS already
>> provides one built-in.
>
> Unfortunately, they are neither re-entrant nor thread-safe. Since
> goroutines are green threads, the whole app would be frozen if any one
> goroutine did a DNS lookup.
Other languages with green threads have dealt with this without having
to roll their own DNS. Both Mac and Linux have getaddrinfo_a, which
does async lookups.
> Caching is done by DNS servers, not by DNS client libraries.
My understanding is that, at least on Mac OS, the DirectoryServices
daemon does local caching for performance reasons.
Another issue I just realized: Go on Mac probably doesn't support
multicast-DNS (Bonjour) hostnames, i.e. the ".local" TLD.
—Jens
Russ Cox
> On Nov 11, 2009, at 1:09 AM, Russ Cox wrote:
>> In particular, on a Mac if you have the firewall enabled
>> it won't let programs listen on UDP sockets, which the
>> Go DNS resolver needs to do.
>
> Does Go really need to run its own DNS resolver?
No, but it was a great way to get off the ground.
> Every OS already provides one built-in. Even if Go's is
> better in some way, it's going to be handicapped by
> needing to open a UDP listener port (which I think will be
> problematic on the future in Windows too, as well as
> Mac OS), as well as not sharing a DNS cache with other processes.
The 6g/8g/etc tool chain doesn't link against standard libraries,
because the calling conventions are different, because the segmented
stack model is very different, and because we want to be able to
start fresh instead of starting by pulling in the entire software stack
that already exists.
I'd like to interact with the system DNS resolver on the Mac, but
just like with the Windows port, we have finite resources and
more things are pressing. I assume that on the Mac the DNS
resolver is some Mach service and can be RPCed to. That's
possible to make work if we could find some documentation
on the Mac side to find out exactly what it involves.
> Perhaps the custom DNS could be included as an opt-in option
> for programs that really want its extra features(?), but the library
> defaults to using the OS's DNS.
If DNS resolution were a system call, this would be trivial and done.
The problem is that it is different on each system. Again, if someone
can explain what needs to happen (without saying "just link against
this library"), then that would speed the process. And if someone
wants to write the code, that would speed it even more.
We understand that using the same DNS resolver that all the other
programs do is a good thing; we just don't know how to do it yet.
Russ
Daniel Spangler
don't have to completely turn it off when performing http requests?
On Nov 11, 1:07 pm, Russ Cox <r...@golang.org> wrote:
Russ Cox
<daniel....@gmail.com> wrote:
> Does anyone know of a way of adjusting the osx firewall such that we
> don't have to completely turn it off when performing http requests?
out how to talk to the system DNS resolver (probably over
Mach RPC), and implement that. If anyone knows details,
I'd be happy to hear them.
Russ