IPv4 established connection paradox

[Aaron Wiebe]

I apologize for bringing this to the list, but after several hours of
google, testing, and so forth I'm coming up blank.  I've been unable
to reproduce this state in targeted tests, however the application
itself does it on a semi-regular basis.

I currently have an application with the following state

(from netstat):
tcp        0      0 127.0.0.1:51115             127.0.0.1:51115
     ESTABLISHED 46965/python2.6
(from lsof):
python2.6 46965 root   14u  IPv4 11218239      0t0     TCP
localhost:51115->localhost:51115 (ESTABLISHED)

The application is blocked in recvfrom() on that socket.

I'm not looking for any specific assistance except the basic one:  how
is it possible to get into this state?  In my tests, binding to the
same port outgoing as a listener isn't possible (not surprised), and
if that's the case, how is it possible to ever have an established
connection to... the same socket.  This is effectively blocking binds
to the port (which is actually used by another application most of the
time).  The application would normally connect to this port to
status-check the running service.  In this case, the service is unable
to start because of this state.

Older RHEL6.6 kernel (2.6.32-431), but if this is a bug I can't seem
to find any mention of it anywhere.  And if it's not, I'm totally
confused and hoping someone can explain this to me.

(Please cc me in response)

-Aaron
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/