Migrated from https://github.com/tensorflow/tensorflow/issues/9480, where it has 6 :+1:s
I use tensorboard on Win7.
Everyting works fine and the cmd shows "Starting TensorBoard b'47' at http://0.0.0.0:6006
"
But when I input "http://0.0.0.0:6006" into chrome, nothing happens.
I google for it but find limited answer.
Then I input "http://localhost:6006" into chrome, the page comes out.
Maybe we should just print the string "localhost" rather than "0.0.0.0"? Would that work cross-platform? @wchargin / @jart do you have thoughts?
This is a post I made on StackOverflow yesterday https://stackoverflow.com/questions/48819139/tensorboard-link-wont-load-tensorflow-graphs-page-in-browser-the-connection-wa
It's not quite the same problem but I'm now more confused because entering 0.0.0.0.6006 gives me access to the TF graphs page. Not really sure what is the reason for this working over the given link from the TF command prompt session initialization (TensorBoard 1.5.1 at http://Andrews-MacBook-Pro.local:6006). I should also note I'm using Firefox on MacOS.
Can you try just using the --host flag to TensorBoard to specify a working host? I'm guessing that localhost or 127.0.0.1 should work for you as values.
TensorBoard has some logic where if you don't pass --host explicitly, it tries to bind to all IP addresses and then it spits out a link using the inferred hostname of the resulting socket - you can see this logic here:
https://github.com/tensorflow/tensorboard/blob/1.6.0/tensorboard/program.py#L231
I guess for your machine that's resulting in the .local address, even though it's not actually a resolvable hostname locally. It's possible we can make this logic smarter to default to using localhost more aggressively (since I expect that most users not using --host are in fact running TensorBoard locally).
For example, it could try resolving the resulting socket name locally to see if it can reach itself. But it's a trade-off since there may be users relying on the default behavior of just blindly using the socket hostname in this case.
As an aside, I'm a bit surprised that you're able to enter 0.0.0.0 in your browser and get a useful result, since 0.0.0.0 is normally only used as a bind address (meaning "all interfaces") and what it would mean as a destination address is unspecified. Apparently people do use it though and expect it to map to localhost, since Chrome tried to disable it and got pushback: https://bugs.chromium.org/p/chromium/issues/detail?id=428046
Also, re @dandelionmane in comment 2 above, I think in cases where 0.0.0.0 resolves it seems to pretty much always be resolved to localhost, so if we get back 0.0.0.0 as the socket hostname, it's probably an improvement in portability to convert it to localhost or 127.0.0.1 (I'm guessing the latter is maximally portable). That would at least fix this issue for the OP.
@nfelt When you say to use --host flag what do you mean (what should I specifically input to either command prompt or broswer address?). I will give localhost or 127.0.0.1 a shot but I'm a beginner in the world of TF so explicit instructions would be very appreciated. Thanks a lot for the explanation!
Try just running tensorboard --host localhost --logdir=output. If that doesn't work, try replacing localhost with 127.0.0.1.
_Results:_
E0216 14:57:06.156283 MainThread program.py:260] TensorBoard attempted to bind to port 6006, but it was already in use
TensorBoard 1.5.1 at http://127.0.0.1:6006 (Press CTRL+C to quit)
Which great success, led me to a proper loading of TF graph page!
Thank you for your detailed explanation and effort!
Glad to hear that worked for you. Re: the first error, that's a bit surprising, and usually would mean you already had TensorBoard (or something else) running on port 6006. I'm able to launch TensorBoard on my mac with --host localhost, so it might be something specific to your setup that's a bit different.
I'm closing this as the original issue appears to be resolved. Please reopen if there is a remaining problem.
Most helpful comment
Try just running
tensorboard --host localhost --logdir=output. If that doesn't work, try replacinglocalhostwith127.0.0.1.