From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id D34C03949097 for ; Tue, 4 May 2021 09:45:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D34C03949097 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 1449jXYr041661 for ; Tue, 4 May 2021 02:45:33 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdrkutYf; Tue May 4 02:45:29 2021 Subject: Re: python > 3.5: Issue with unix domain sockets From: Mark Geisert To: cygwin-developers@cygwin.com References: <1620046759893.5340@bmw.de> <2cde4128-6a3d-7431-6608-a2184d23964a@cornell.edu> Message-ID: <134fa003-836f-1184-79eb-e31dfd852a64@maxrnd.com> Date: Tue, 4 May 2021 02:45:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 09:45:35 -0000 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 >>>      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: 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 >>>      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