By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,584 Members | 1,774 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,584 IT Pros & Developers. It's quick & easy.

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

P: n/a

I'm receiving the following error during startup:

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

Aug 10 14:11:27 thunder postgres[18619]: [2-1] LOG: database system was
shut down at 2003-08-10 14:11:11 MDT

Aug 10 14:11:27 thunder postgres[18619]: [3-1] LOG: checkpoint record is
at 4/E28389B4

Aug 10 14:11:27 thunder postgres[18619]: [4-1] LOG: redo record is at
4/E28389B4; undo record is at 0/0; shutdown TRUE

Aug 10 14:11:27 thunder postgres[18619]: [5-1] LOG: next transaction
id: 80139; next oid: 35014046

Aug 10 14:11:27 thunder postgres[18619]: [6-1] LOG: database system is
ready

And yet everything appears to be working fine. Something I've done
wrong in the build/configure?

tassiv=# select version();
version

-----------------------------------------------------------------------
------------------------------------ PostgreSQL 7.4beta1 on
i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 (Mandrake Linux 9.1
3.2.2-3mdk)

Cheers,
Rob

--
14:51:35 up 9 days, 7:37, 4 users, load average: 1.13, 1.18, 1.03

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iEYEARECAAYFAj82sRkACgkQgy51bQc2FFmM1ACgrTsHWN7I01 CbiVboM6l8mfSn
3VAAni2iaJ94TcmH4GtThg54sWyijeoz
=zpmu
-----END PGP SIGNATURE-----

Nov 11 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Robert Creager <Ro************@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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 11 '05 #2

P: n/a

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 <Ro************@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
pg***@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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 11 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.