Thread: Bogus bind() warnings
When I start up with -i, I get the following log: LOG: could not bind IPv4 socket: Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. LOG: database system was shut down at 2003-11-06 20:47:54 CET LOG: checkpoint record is at 0/9B6E08 LOG: redo record is at 0/9B6E08; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 538; next OID: 17143 LOG: database system is ready There is no other postmaster running anywhere. I suspect that this has to do with IPv6. This is a SuSE 8.something machine that is relatively fully IPv6 enabled. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> When I start up with -i, I get the following log:
> LOG: could not bind IPv4 socket: Address already in use
> There is no other postmaster running anywhere. I suspect that this has to
> do with IPv6. This is a SuSE 8.something machine that is relatively fully
> IPv6 enabled.
Is it possible that that kernel considers binding to an IPv6 port to
conflict with binding to the "same" port number as an IPv4 port?
IIRC that was the behavior we once expected would happen, but later
found out that most kernels don't (yet?) act that way. The present
design of trying to bind to both IPv6 and IPv4 sockets would be
unnecessary if the kernels acted more rationally.
regards, tom lane
Tom Lane writes:
> Is it possible that that kernel considers binding to an IPv6 port to
> conflict with binding to the "same" port number as an IPv4 port?
I don't understand this business, but if it helps, below is my ifconfig
output.
eth0 Link encap:Ethernet HWaddr 00:40:F6:74:BE:71 inet6 addr: fe80::240:f6ff:fe74:be71/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:440903 errors:0 dropped:0 overruns:0 frame:0
TX packets:301944 errors:5 dropped:0 overruns:0 carrier:3 collisions:0 txqueuelen:100 RX
bytes:189774879(180.9 Mb) TX bytes:64786361 (61.7 Mb) Interrupt:11 Base address:0xd800
eth1 Link encap:Ethernet HWaddr 00:50:22:80:A9:6E inet addr:192.168.100.1 Bcast:192.168.100.255
Mask:255.255.255.0 inet6 addr: fe80::250:22ff:fe80:a96e/10 Scope:Link UP BROADCAST RUNNING MULTICAST
MTU:1500 Metric:1 RX packets:99975 errors:0 dropped:0 overruns:0 frame:0 TX packets:126153 errors:0
dropped:0overruns:0 carrier:0 collisions:8425 txqueuelen:100 RX bytes:15633278 (14.9 Mb) TX
bytes:52753463(50.3 Mb) Interrupt:9 Base address:0x9000
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:107127 errors:0 dropped:0 overruns:0 frame:0
TXpackets:107127 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20827790
(19.8Mb) TX bytes:20827790 (19.8 Mb)
ppp0 Link encap:Point-to-Point Protocol inet addr:82.82.161.250 P-t-P:145.253.4.3 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:37103 errors:0 dropped:0 overruns:0
frame:0 TX packets:23882 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX
bytes:4652420(4.4 Mb) TX bytes:5807647 (5.5 Mb)
sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0
frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX
bytes:0(0.0 b) TX bytes:0 (0.0 b)
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I don't understand this business, but if it helps, below is my ifconfig
> output.
Hmm, you have a bunch of addresses don't you? It looks like we should
have included more information in the report of bind failures, like
exactly which address failed. Can you step through StreamServerPort,
or perhaps just strace postmaster startup, to observe the sequence of
bind() calls? It would be useful to know which addresses have already
been bound and which one is failing.
regards, tom lane
Tom Lane wrote: >Peter Eisentraut <peter_e@gmx.net> writes: > > >>When I start up with -i, I get the following log: >>LOG: could not bind IPv4 socket: Address already in use >> >> > > > >>There is no other postmaster running anywhere. I suspect that this has to >>do with IPv6. This is a SuSE 8.something machine that is relatively fully >>IPv6 enabled. >> >> > >Is it possible that that kernel considers binding to an IPv6 port to >conflict with binding to the "same" port number as an IPv4 port? > >IIRC that was the behavior we once expected would happen, but later >found out that most kernels don't (yet?) act that way. The present >design of trying to bind to both IPv6 and IPv4 sockets would be >unnecessary if the kernels acted more rationally. > > > I have seen this before, and reported it, but can't find the thread right now. On Linux with IP6 enabled, IP4 is tunnelled over IP6 - they *are* the same sockets, AFAIK. Didn't we put in a patch after lengthy discussion that fixes things from a pg_hba.conf POV exactly to handle this (i.e. to match an IP4 address in the file with the corresponding IP6 address: n.n.n.n/x -> ::ffff:n.n.n.n/96+x )? I also recall someone saying this would change in later versions of Linux. cheers andrew
>> Is it possible that that kernel considers binding to an IPv6 port to
>> conflict with binding to the "same" port number as an IPv4 port?
Actually, I think that that may be expected behavior depending on the
vintage of the kernel. Note the following comment in
StreamServerPort():
/* * Note: This might fail on some OS's, like Linux older than * 2.4.21-pre3, that don't have the
IPV6_V6ONLYsocket option, and * map ipv4 addresses to ipv6. It will show ::ffff:ipv4 for all * ipv4
connections. */
regards, tom lane
On Thu, Nov 06, 2003 at 03:42:39PM -0500, Tom Lane wrote: > >> Is it possible that that kernel considers binding to an IPv6 port to > >> conflict with binding to the "same" port number as an IPv4 port? > > Actually, I think that that may be expected behavior depending on the > vintage of the kernel. Note the following comment in > StreamServerPort(): > > /* > * Note: This might fail on some OS's, like Linux older than > * 2.4.21-pre3, that don't have the IPV6_V6ONLY socket option, and > * map ipv4 addresses to ipv6. It will show ::ffff:ipv4 for all > * ipv4 connections. > */ Maybe my comment isn't clear enough ... It fails on Linux in case you first bind the AF_INET6 socket to ::, and then try to bind to AF_INET 0.0.0.0, and don't have the IPV6_V6ONLY options. You have this problem from the moment you enable ipv6 support in your kernel. The real fix is to get a kernel/libc that has the IPV6_V6ONLY socket option. Being unable to bind to the port isn't a problem in case you already got the AF_INET6 one. But maybe it might confuse some users who then think something is wrong. Should we just not give that error message, in case we already binded to AF_INET6 ::? Kurt
Kurt Roeckx <Q@ping.be> writes:
> Should we just not give that error message, in case we already
> binded to AF_INET6 ::?
Seems like a cure worse than the disease to me --- it could mask
real problems. I suppose we could think about dropping it from LOG
to DEBUG1 level, so that it wouldn't appear in a default setup;
but I'm not sure I'm for that either.
Given the, ahem, wide variety of behaviors that seem to be out there,
I think we'd best be happy if we have a v4/v6 implementation that has
no problems worse than spurious log messages ...
regards, tom lane
Tom Lane wrote: >Kurt Roeckx <Q@ping.be> writes: > > >>Should we just not give that error message, in case we already >>binded to AF_INET6 ::? >> >> > >Seems like a cure worse than the disease to me --- it could mask >real problems. I suppose we could think about dropping it from LOG >to DEBUG1 level, so that it wouldn't appear in a default setup; >but I'm not sure I'm for that either. > >Given the, ahem, wide variety of behaviors that seem to be out there, >I think we'd best be happy if we have a v4/v6 implementation that has >no problems worse than spurious log messages ... > > I agree. Things that might be serious problems should not be hidden. Maybe it would be better to add a message that the error might be harmless if you have IPv6 turned on. cheers andrew
Tom Lane writes: > Actually, I think that that may be expected behavior depending on the > vintage of the kernel. Note the following comment in > StreamServerPort(): Can we make the warning less misleading if IPV6_V6ONLY does not exist? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Actually, I think that that may be expected behavior depending on the
>> vintage of the kernel. Note the following comment in
>> StreamServerPort():
> Can we make the warning less misleading if IPV6_V6ONLY does not exist?
Possibly. How would you like to phrase it? (And do you want to break
the strings freeze at this point?)
regards, tom lane