New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error listening, but site is served anyway #8

Closed
simendsjo opened this Issue Apr 27, 2012 · 12 comments

Comments

Projects
None yet
5 participants
@simendsjo
Contributor

simendsjo commented Apr 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@zhaopuming

zhaopuming Apr 27, 2012

I got this error too.

zhaopuming commented Apr 27, 2012

I got this error too.

@ricochet1k

This comment has been minimized.

Show comment
Hide comment
@ricochet1k

ricochet1k Apr 27, 2012

Contributor

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

Contributor

ricochet1k commented Apr 27, 2012

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

@simendsjo

This comment has been minimized.

Show comment
Hide comment
@simendsjo

simendsjo Apr 27, 2012

Contributor

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

Contributor

simendsjo commented Apr 27, 2012

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

@ricochet1k

This comment has been minimized.

Show comment
Hide comment
@ricochet1k

ricochet1k Apr 27, 2012

Contributor

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.

Contributor

ricochet1k commented Apr 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Apr 28, 2012

Member

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.

Member

s-ludwig commented Apr 28, 2012

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.

@ghost ghost assigned s-ludwig Apr 28, 2012

@ricochet1k

This comment has been minimized.

Show comment
Hide comment
@ricochet1k

ricochet1k Apr 28, 2012

Contributor

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

Contributor

ricochet1k commented Apr 28, 2012

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

@simendsjo

This comment has been minimized.

Show comment
Hide comment
@simendsjo

simendsjo Apr 28, 2012

Contributor

Me too. Enabling IPv6 fixed the "issue"

Contributor

simendsjo commented Apr 28, 2012

Me too. Enabling IPv6 fixed the "issue"

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Apr 29, 2012

Member

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.

Member

s-ludwig commented Apr 29, 2012

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.

@klickverbot

This comment has been minimized.

Show comment
Hide comment
@klickverbot

klickverbot Apr 29, 2012

Contributor

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?

Contributor

klickverbot commented Apr 29, 2012

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

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Apr 29, 2012

Member

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

Member

s-ludwig commented Apr 29, 2012

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

@klickverbot

This comment has been minimized.

Show comment
Hide comment
@klickverbot

klickverbot Apr 29, 2012

Contributor

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.

Contributor

klickverbot commented Apr 29, 2012

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

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Sep 5, 2013

Member

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)

Member

s-ludwig commented Sep 5, 2013

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment