7.4Beta1 "failed to create socket: Address family not supported by protocol"

Robert Creager <Robert_Creager@LogicalChaos.org> writes:

Aug 10 14:11:27 thunder postgres[18613]: [1-1] LOG: failed to create
socket: Address family not supported by protocol

It's normal for this to happen if you have userland (libc) code that
supports IPv6 but your kernel isn't configured to do so. The postmaster
will try to create both IPv4 and IPv6 sockets, because getaddrinfo()
told it to, but the IPv6 attempt will fail as above.

However, I can see that this is going to become a FAQ if we leave the
behavior alone. I am wondering if we can suppress this message without
making life difficult for people who are trying to debug actual problems
in setting up sockets.

We could just ignore EAFNOSUPPORT failures, but I'm not sure if there
are any cases where such an error would genuinely be interesting.
Another possibility is to issue the per-failure messages at a very low
level (DEBUG2 maybe) and only LOG when we can't create any socket at
all. Perhaps there are better answers. Any ideas?

regards, tom lane

My original commit had a message stating it was an IPv6 and the kernel
didn't support it. I don't see that message in CVS anymore, but I think
we need something similar.

There was a big discussion over whether we should require IPv6 to be
enabled individually, and then throw a hard error if IPv6 fails, but at
this stage, it seemed best to most to just try IPv6 and soft-fail, while
throwing a message in the server logs.

---------------------------------------------------------------------------

Tom Lane wrote:

Robert Creager <Robert_Creager@LogicalChaos.org> writes:

Aug 10 14:11:27 thunder postgres[18613]: [1-1] LOG: failed to create
socket: Address family not supported by protocol

It's normal for this to happen if you have userland (libc) code that
supports IPv6 but your kernel isn't configured to do so. The postmaster
will try to create both IPv4 and IPv6 sockets, because getaddrinfo()
told it to, but the IPv6 attempt will fail as above.

However, I can see that this is going to become a FAQ if we leave the
behavior alone. I am wondering if we can suppress this message without
making life difficult for people who are trying to debug actual problems
in setting up sockets.

We could just ignore EAFNOSUPPORT failures, but I'm not sure if there
are any cases where such an error would genuinely be interesting.
Another possibility is to issue the per-failure messages at a very low
level (DEBUG2 maybe) and only LOG when we can't create any socket at
all. Perhaps there are better answers. Any ideas?

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

There was a big discussion over whether we should require IPv6 to be
enabled individually, and then throw a hard error if IPv6 fails, but at
this stage, it seemed best to most to just try IPv6 and soft-fail, while
throwing a message in the server logs.

The real problem is perhaps that the message gives no hint that it's
talking about being unable to establish an IPv6 socket. With that hint,
perhaps people would realize that it's not a problem.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

There was a big discussion over whether we should require IPv6 to be
enabled individually, and then throw a hard error if IPv6 fails, but at
this stage, it seemed best to most to just try IPv6 and soft-fail, while
throwing a message in the server logs.

The real problem is perhaps that the message gives no hint that it's
talking about being unable to establish an IPv6 socket. With that hint,
perhaps people would realize that it's not a problem.

Yes, that was my point, that in the initial message wording I had
mentioned IPv6, and the fact that it wasn't enabled in the kernel.

Not sure who took it out, but it gone. The original message was:

elog(LOG, "IPv6 support disabled --- perhaps the kernel does not support IPv6");

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

The real problem is perhaps that the message gives no hint that it's
talking about being unable to establish an IPv6 socket. With that hint,
perhaps people would realize that it's not a problem.

Not sure who took it out, but it gone. The original message was:
elog(LOG, "IPv6 support disabled --- perhaps the kernel does not support IPv6");

That seems both wordy and not necessarily accurate. What I had in mind
was more like

"could not create IPv6 socket: %m"

But I still wonder whether we shouldn't suppress the message entirely,
at least for EAFNOSUPPORT errors.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

The real problem is perhaps that the message gives no hint that it's
talking about being unable to establish an IPv6 socket. With that hint,
perhaps people would realize that it's not a problem.

Not sure who took it out, but it gone. The original message was:
elog(LOG, "IPv6 support disabled --- perhaps the kernel does not support IPv6");

That seems both wordy and not necessarily accurate. What I had in mind
was more like

"could not create IPv6 socket: %m"

But I still wonder whether we shouldn't suppress the message entirely,
at least for EAFNOSUPPORT errors.

If we suppress it entirely, there is no user-visible report that IPv6
isn't enabled on this computer, though if your kernel doesn't support
it, you would think they would know that, but I suspect many people
don't know it has to be enabled in the kernel --- hence the wording of
the original message.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

But I still wonder whether we shouldn't suppress the message entirely,
at least for EAFNOSUPPORT errors.

If we suppress it entirely, there is no user-visible report that IPv6
isn't enabled on this computer, though if your kernel doesn't support
it, you would think they would know that, but I suspect many people
don't know it has to be enabled in the kernel --- hence the wording of
the original message.

I don't see your point at all. If they don't have IPv6 enabled in the
kernel, they don't need it. Or if they do, Postgres launch is surely
not going to be the place where they discover they need it.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

But I still wonder whether we shouldn't suppress the message entirely,
at least for EAFNOSUPPORT errors.

If we suppress it entirely, there is no user-visible report that IPv6
isn't enabled on this computer, though if your kernel doesn't support
it, you would think they would know that, but I suspect many people
don't know it has to be enabled in the kernel --- hence the wording of
the original message.

I don't see your point at all. If they don't have IPv6 enabled in the
kernel, they don't need it. Or if they do, Postgres launch is surely
not going to be the place where they discover they need it.

That's a good point. Will they find they don't have IPv6 enabled in the
kernel before trying to make an IPv6 connection, perhaps from another
machine or from the local machine?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073