cli: unusable ui url printed when $(hostname) doesn't resolve

[wendigo]

Is this a question, feature request, or bug report?

When running cockroach in single-node on macOS:

cockroach start --insecure

CockroachDB node starting at 2017-05-26 19:29:00.429726493 +0200 CEST
build:      CCL v1.0.1 @ 2017/05/25 17:12:12 (go1.8.3)
admin:      http://polpc02585:8080
sql:        postgresql://root@polpc02585:26257?sslmode=disable
...

While accessing web UI I got following errors on requests to _status/*: grpc: the connection is unavailable"

I have observed that this error is caused by my hostname not being resolvable to any IP:

~ hostname
polpc02585
~ ping polpc02585
ping: cannot resolve polpc02585: Unknown host

When I've added 127.0.0.1 polpc02585 to /etc/hosts everything works fine.

So my best guess is that cockroach should not use hostname name if it's not resolvable.

[tbg]

@wendigo thanks for your report! if your hostname isn't resolvable, use --http-host 127.0.0.1 and the problem will go away. Our ergonomics here are off - not sure what good other options are; but definitely not printing a hostname we know is not resolvable.

We in fact do something a little weird here, namely even when you use

./cockroach start --advertise-host=127.0.0.1 --insecure

then the printed UI endpoint still uses the inferred hostname, but at the SQL endpoint picks it up. This is unrelated, but perhaps that's also incorrect - --advertise-host is for intra-cluster communication.

Perhaps also related to #8832, #10374.

[petermattis]

I mentioned this same idea somewhere else recently (but I never filed an issue): we should try resolving os.Hostname() before using it. Not having a resolvable hostname seems to be a very common configuration and source of errors.

[wendigo]

I agree. Recently I had to reinstall macOS from scratch and default hostname is not resolvable thus creating situation I've described which can be surprising to many unexperienced users.