python > 3.5: Issue with unix domain sockets
Mark Geisert
mark@maxrnd.com
Tue May 4 09:45:30 GMT 2021
Mark Geisert wrote:
> Ken Brown via Cygwin wrote:
>> On 5/3/2021 8:57 AM, Maximilian.Blenk--- via Cygwin wrote:
>>> Incorrect Behavior:
>>> Server:
>>> $ python3.7 server.py
>>> starting up on ./uds_socket
>>> waiting for a connection
>>> Traceback (most recent call last):
>>> File "server.py", line 27, in <module>
>>> connection, client_address = sock.accept()
>>> File "/usr/lib/python3.7/socket.py", line 214, in accept
>>> sock = socket(self.family, self.type, self.proto, fileno=fd)
>>> File "/usr/lib/python3.7/socket.py", line 151, in __init__
>>> _socket.socket.__init__(self, family, type, proto, fileno)
>>> SystemError: <slot wrapper '__init__' of '_socket.socket' objects> returned
>>> NULL without setting an error
>>>
>>> Client:
>>> $ python3.7 client.py
>>> connecting to ./uds_socket
>>> sending b'This is the message. It will be repeated.'
>>> closing socket
>>> Traceback (most recent call last):
>>> File "client.py", line 27, in <module>
>>> data = sock.recv(16)
>>> ConnectionResetError: [Errno 104] Connection reset by peer
>>
>> I wonder if this has the same cause as the problem reported here:
>>
>> https://cygwin.com/pipermail/cygwin/2021-February/247884.html
>>
>> Mark, can you check that?
This issue is indeed related to the Python patch released to Python 3.{6,7,8} but
not Python 3.5 or earlier. I'm discussing here because the situation involves
Python internals doing socket operations and Cygwin's AF_UNIX support is shaky in
some aspects (that Ken's work will likely fix to the relief of everyone!).
The purpose of the Python patch is to disable the normal peer handshake that
starts each AF_UNIX connection. So whenever a Python app obtains an AF_UNIX
socket, either from socket() or accept(), the internal routine that inits
Python-level state was patched to call setsockopt() to turn off the handshake.
But it turns out that fhandler_socket_local::accept4() sets the socket's
connect_state to "connected", on line fhandler_socket_local.cc:1086. Then when
the wrapping Python patch calls setsockopt() we end up in
::af_local_set_no_getpeereid(), which is good, but the socket is marked
"connected" so the result is an EALREADY error that rather clumsily knocks out
both the server and client apps.
Assuming the connect_state check is needed (seems good for sanity check if nothing
else) then I think I need to adjust when the Python patch is invoked. Possibly
distinguishing between Python-level accept()'s listening socket and returned
socket. I think that's right, assuming the Cygwin parts are operating correctly.
Does this sound like the right way to go?
Thanks for any comments either way.
..mark
More information about the Cygwin-developers
mailing list