[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAPjSzr9xVTAUC2nJ5amrwJAjGCM0FfmRNBigbUgGc4PQiyrhSA@mail.gmail.com>
Date: Wed, 25 Mar 2015 15:42:15 +0900
From: Aaron Wiebe <epiphani@...il.com>
To: linux-kernel@...r.kernel.org
Subject: IPv4 established connection paradox
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists