From: Christian Franke <Christian.Franke@t-online.de>
To: cygwin@cygwin.com
Subject: Re: connect() hangs on a listen()ing AF_UNIX socket
Date: Thu, 21 Aug 2014 19:14:00 -0000 [thread overview]
Message-ID: <53F6450C.3070007@t-online.de> (raw)
In-Reply-To: <20140821164402.GB21065@calimero.vinschen.de>
Corinna Vinschen wrote:
> On Aug 21 18:16, Christian Franke wrote:
>> Corinna Vinschen wrote (in thread "[ITP] libsuexec 1.0"):
>>> Postfix for Cygwin would be *so* nice. Sigh. ...
>> Due to the following problem, Postfix hangs during startup (and blocks any
>> possible "[ITP] postfix ..."):
>>
>> If a AF_UNIX socket is in listen()ing state, a client connect() should
>> succeed immediately. On Cygwin, connect() waits until the server site
>> accept()s the connection.
>>
>> Testcase:
>> ...
>>
>>
>> This is likely because fhandler_socket::af_local_connect() waits for some
>> secret. Sending it in af_local_accept() is too late in this case.
>>
>> Unfortunately the event handling of postfix relies on the correct behavior
>> and there is possibly no easy workaround.
> Off the top of my head I don't see one inside the Cygwin DLL :(
Complex but may work: A fhandler_socket::listen() on a
AF_UNIX/SOCK_STREAM socket starts a thread which accept()s connections,
performs the handshake and puts the new socket descs in a queue.
fhandler_socket::accept4() then no longer calls accept() but waits for
the next entry in the queue.
> The problem is that the package exchange at the start of an
> accept/connect is required to be able to exchange credentials. This in
> turn is required for getpeereid and the SO_PEERCRED socket option which
> is utilized at least by sshd.
Easier and may work for Postfix: Add a Cygwin specific socket option
like SO_DONT_NEED_PEERCRED which is set immediately after Postfix calls
socket(AF_UNIX, SOCK_STREAM). If set, no handshake occurs on
connect()/accept(). getpeerid()/SO_PEERCRED should fail then.
> Would it help to patch postfix for Cygwin to use a local-only AF_INET
> socket at this point instead?
Postfix heavily relies on unix domain sockets (see master.cf) so this
would possibly be complex. Such a patch would likely not be accepted
upstream.
Christian
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next prev parent reply other threads:[~2014-08-21 19:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-21 16:17 Christian Franke
2014-08-21 16:44 ` Corinna Vinschen
2014-08-21 19:14 ` Christian Franke [this message]
2014-08-22 9:39 ` Corinna Vinschen
2014-08-22 18:32 ` Christian Franke
2014-08-22 20:16 ` Corinna Vinschen
2014-08-26 19:03 ` Christian Franke
2014-08-26 20:56 ` Corinna Vinschen
2014-08-27 8:58 ` Achim Gratz
2014-08-27 9:50 ` Corinna Vinschen
2014-08-27 10:12 ` Corinna Vinschen
2014-08-27 17:57 ` Achim Gratz
2014-08-28 9:57 ` Corinna Vinschen
2014-09-25 14:35 ` Christian Franke
2014-10-08 12:39 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53F6450C.3070007@t-online.de \
--to=christian.franke@t-online.de \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).