Error listening, but site is served anyway

[simendsjo]

It tries to bind to the same port twice..?

[7FA48783CF00:00000000 WRN] Failed to parse config file /etc/vibe/vibe.conf: /etc/vibe/vibe.conf: No such file or directory
[7FA48783CF00:00000000 INF] Listening on 0.0.0.0 port 8080 succeeded
[7FA48783CF00:00000000 ERR] Error binding listening socket
[7FA48783CF00:00000000 INF] Listening on :: port 8080 failed
[7FA48783CF00:00000000 INF] Running event loop...

[zhaopuming]

I got this error too.

[ricochet1k]

It's trying to listen using IPv4 and IPv6 at the same time, which for some reason is breaking.

[simendsjo]

Ah. Should probably add the version to the message then.

[ricochet1k]

I just derived that information from 0.0.0.0 vs ::.

So anyway, it looks like your computer probably doesn't have the ability to listen with IPv6. The error can probably just be ignored.

[s-ludwig]

Right, it tries to listen on both and the IPv6 one always fails. I'm not yet sure why the IPv6 one fails. But since listenTcp/listenHttp should actually fail with an exception if the socket bind fails, this needs to be fixed/detected in advance. Up to then it can be safely ignored.

[ricochet1k]

I have explicitly disabled IPv6 on my computer, that's why it fails for me.

[simendsjo]

Me too. Enabling IPv6 fixed the "issue"

[s-ludwig]

Do you know an ad-hoc way to detect this in advance? I would like to make this an actual error with an exception to avoid real "silent" failures.

[dnadlinger]

Get the addresses of the local interface using getaddrinfo with null host, the target port, and AI_PASSIVE, and then listen on one (or more) of them?

[s-ludwig]

Thanks, that sounds like it should work, will do.

[dnadlinger]

Be sure to use really use a null address and a concrete port though – from my related tests (http://klickverbot.at/blog/2012/01/getaddrinfo-edge-case-behavior-on-windows-linux-and-osx/), it looks like only then you'll reliably get on IPv4 and IPv6 on all OSes.

[s-ludwig]

I'll close this with the following rationale:

• listenTCP with no bind addresses will keep quiet (apart from a diagnostic message)
• listenHTTP, since it has an explicit HTTPServerSettings.bindAddresses field, has to output a warning as, after all, this is basically a configuration error. It would be error prone to just ignore a failed bind attempt here
• All examples are using ["::1", "127.0.0.1"] to listen on now, so that the error doesn't happen there

I'm also thinking to make the default ["::1", "127.0.0.1"], too, but that would unfortunately break a lot of applications (even if trivial to fix)