mbtileserver does not start on Windows

[evbarnett]

Following the instructions:

You can install this project with

go get github.com/consbio/mbtileserver

This will create and install an executable called mbtileserver.

However, the command does not install anything. Running it with -v only gives:

C:\>go get -v github.com/consbio/mbtileserver
github.com/consbio/mbtileserver (download)

Thank you for your help

[evbarnett]

Strangely, after running the exact same command 5+ times it suddenly worked.

[brendan-ward]

@evbarnett we don't do this in a Windows environment, so I'm not sure what was causing this problem.

It might be that location where go installs mbtileserver was not originally on your system path, and so it wasn't immediately found on the command line.

Or possibly that it didn't build the first few times you tried go get but eventually built. Without errors, it is hard to troubleshoot that.

[evbarnett]

@brendan-ward Thanks for the reply.

Follow up question- I'm encountering an error upon running:

C:\>mbtileserver -v
time="2019-06-07T12:35:26-06:00" level=fatal msg="file tcp [::]:8000: not supported by windows"

Seems like a strange error and upon a google search I could only find a single occurrence:

coredns/coredns#2002

Following the rabbit hole it seems to be a bug in the Go implementation of ipv4/ipv6 that's been around for a while:

golang/go#7175

golang/go#7174

Do you have any advice? My go version is go1.12.5 windows/amd64 and I'm running this on Windows 10. Thanks again for your help.

[brendan-ward]

@evbarnett is it possible your firewall or other machine-level security settings are getting in the way?

In case it is another application on that port, but not getting reported as such, you could try running on a few other ports, e.g., -p 12345

It might be that recent changes to listen for signals are not working properly on Windows. @nikmolnar ?

Unfortunately, I don't have a Windows 10 machine to test on, so I'm not able to troubleshoot.

[evbarnett]

is it possible your firewall or other machine-level security settings are getting in the way?

Possibly- I have limited control / knowledge about how my computer is restricted (work machine). I'll give it a shot on my personal machine under the same configuration and see if I can replicate.

In case it is another application on that port

Doesn't seem to be the case, error is the same with different ports

C:\>mbtileserver -v -p 5090
time="2019-06-07T13:55:12-06:00" level=fatal msg="file tcp [::]:5090: not supported by windows"

If I need to run the server on this machine, I suppose I could try running it in a linux docker container.

Thanks, if I find a solution I'll reply back.

[nikmolnar]

It might be that recent changes to listen for signals are not working properly on Windows. @nikmolnar ?

@brendan-ward: It's possible. We create the listener explicitly now, whereas it was created implicitly by another library previously. Possibly said library had a workaround for the aforementioned TCP bug in Go.

Do we know that mbtileserver worked on Windows previously?

[evbarnett]

@brendan-ward @nikmolnar It does not work on my personal machine either,I played around with the firewall just in case also, and I could not get it to work. I'm using the same version of Go and getting the same error.

[brendan-ward]

I am able to reproduce on a borrowed Windows 10 machine.

@nikmolnar I confirmed that this is isolated to the introduction of signals for graceful reloading. If I build from the immediately prior commit, everything works properly.

@evbarnett if you need this to work soon, while we're still tracking this down, you can clone the repo and build using this commit: d5769a0

Note: you'll need to have a version of gcc installed (I used TDM-GCC). See: https://github.com/consbio/mbtileserver#development

[brendan-ward]

@nikmolnar see the things unimplemented for Windows here: https://golang.org/pkg/net/#pkg-note-BUG

Since the signals we want to listen on are not available on Windows anyway, what do you think about a split implementation of the startup, where if we detect that we're on Windows we start with no graceful reloading, and otherwise use what you have here?

[brendan-ward]

@nikmolnar I thought about this a bit more, I think the solution I like best is to enable graceful reloading based on a flag when mbtileserver is started. That way we aren't autodetecting environment and changing behavior, but rather it is something where the user opts in, and might not be supported on all platforms. Plus, this makes it easier to develop and test.

[nikmolnar]

That would different from how most other applications handle reload. I've never seen anything else that requires a flag on start to enable reload. Also, I suspect the problem isn't the signals, it's create a file-based TCP listener.

I think the original plan of degrading gracefully to no reload support is still the best approach.

[nikmolnar]

Hi @evbarnett, this issue should be resolved by #72, but I don't have a Windows machine to try it on. Do you want to give it a go?

[evbarnett]

It works, thank you!