From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71044 invoked by alias); 9 Jan 2017 17:16:41 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 70974 invoked by uid 89); 9 Jan 2017 17:16:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-101.6 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=cygwin-apps, cygwinapps, bandwagon, briefly X-HELO: drew.franken.de Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jan 2017 17:16:39 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id 7F543721E280D for ; Mon, 9 Jan 2017 18:16:36 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id D6ABD5E0704 for ; Mon, 9 Jan 2017 18:16:35 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id B630CA804B0; Mon, 9 Jan 2017 18:16:35 +0100 (CET) Date: Mon, 09 Jan 2017 17:16:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect) Message-ID: <20170109171635.GB26337@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20170109141306.GB843@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wzJLGUyc3ArbnUjN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-SW-Source: 2017-01/txt/msg00059.txt.bz2 --wzJLGUyc3ArbnUjN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2991 On Jan 9 16:46, Erik Bray wrote: > Hi Corinna, >=20 > Thanks for the response. >=20 > On Mon, Jan 9, 2017 at 3:13 PM, Corinna Vinschen wrote: > > Right. It has to do with how connect/accept works on AF_LOCAL sockets. > > The handshake doesn't work well for situations like yours, where the > > same thread tries to connect and accept on the same socket. >=20 > Actually I'm not entirely sure now that that's the issue, even > considering that this has come up before. Or at the very least, > there's an additional issue. I realized that when I tried separate > client/server processes, in the server I had put an accept() call at > the end so it would block there. With the server waiting to accept a > connection it succeeded. However, when I replaced the accept() with a > long sleep(), the client's connect() never returns. That's because connect infinitely waits for the accept to reply the second half of the handshake. > IIUC the handshake can't succeed until and unless the server accepts a > connection from the client. This is exactly the underlying problem. And interesting enough, even though the handshake is in Cygwin since 2001, we never had a problem with this until Christian started porting postfix in 2014! > I almost wonder if the server side in this case > shouldn't start up a thread to accept the af_local handshake, but you > would know better. No, I don't. We discussed this issue briefly back in 2014, but as you can see we don't have a solution for this border case yet. Starting a thread may or may not work, but there are a couple of use-cases to keep in mind (which I can't reproduce off the top of my head). The old postfix cygwin-apps thread from 2014 might give you some idea. > > This has been found a problem in porting postfix already and at the time > > we added a patch to circumvent the problem. Before calling connect, add > > this: > > > > setsockopt (sock_server, SOL_SOCKET, SO_PEERCRED, NULL, 0); > > setsockopt (sock_client, SOL_SOCKET, SO_PEERCRED, NULL, 0); > > > > This is, of course, a hack. The problem here is that server and client > > of a socket are independent of each other, and there's typically no > > way to know which process created the server side unless you already > > are connected. Chicken/egg. >=20 > I tried it and it worked, both in the single process and separate > process examples. I see now--this sets > fhandler_socket::no_getpeerid=3Dtrue, so it doesn't have to do the > handshake at all. Right. A better solution for the problem would be nice. Ultimately we want to check if the other side of the socket is actually a Cygwin process which knows the secret, not a stray native Windows process which accidentally hopped on the bandwagon, and we want to exchange the credentials so a subsequent SO_PEERCRED call returns correct values. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --wzJLGUyc3ArbnUjN Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYc8VzAAoJEPU2Bp2uRE+glMgQAIgZNmC2/2WHYKo7wTsvK1gZ w92QDfTmEXnfCrlhmv/zUEd6Ej4tHbi2bcb4a2TxsNrKervrx9TJep06WsyjdLRT LJcmKi/R6rVfr+NCuC9+UavouOUa1ZLXBcvYljDdVMLqq0TbKACLVd/RxrdD2y9l n6GU0ltmdBtbP2yDpdtit+Fgxu5yi+zLj9kri0C9iLYOCUYJiMxTGyvZ9wTGBH9R xRf44YdJkDjTTGaU4XRgw936A3DbDj4H2Ww14OzcRFlJEuQfLyh9xO9pH+Qergqu 5uyif4STdwTtj0KC6VhE7DQ66lT6FZUiVS7au52fOMDdVIRYnfbrL+kmTcL20KbU F3vJDblOcL4jYXKuGeykb0oBTL+KMJqiHVeV/FOPOezBkXXw0Fb8rF4+3xH8X3Iz e4j5+JRBwNEDSiduN5i68VRjFNFBt7Rhqs+cZtDcgZoRFEkBmRo5I63Euv301Kp/ HKkjqFPiSt66e7P1+ucxIjmpwtBfFMw/nT2evRvQp4v3sUBg4hOfdVnApYMsmme4 s9f2OounFVftCf/us2VOx5dnkzs1olw2WqCFlua/Astn19vm2UidtA+/LaZwRPDe u3D/ycDdGt2O4D8//7TNeicDfpc6wzNZWUw8rZXkPddDzVVCd/Ug5QfnFe56fj/F 5+k+xXGDTV1IJleMfvBY =KH1u -----END PGP SIGNATURE----- --wzJLGUyc3ArbnUjN--