connect() hangs on a listen()ing AF_UNIX socket

connect() hangs on a listen()ing AF_UNIX socket

[Christian Franke]

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:

#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>

int main()
{
   sockaddr_un sa = {AF_UNIX, "testsocket"};
   unlink(sa.sun_path);

   int sd1 = socket(AF_UNIX, SOCK_STREAM, 0);
   if (sd1 < 0) {
     perror("socket"); return 1;
   }
   if (bind(sd1, (sockaddr*) &sa, sizeof(sa))) {
     perror("bind"); return 1;
   }
   if (listen(sd1, 10) < 0) {
     perror("listen"); return 1;
   }

   int sd2 = socket(AF_UNIX, SOCK_STREAM, 0);
   if (sd2 < 0) {
     perror("socket"); return 1;
   }
   printf("connecting to %s ...\n", sa.sun_path);

   // Cygwin hangs here:
   if (connect(sd2, (sockaddr*) &sa, sizeof(sa))) {
     perror("connect"); return 1;
   }

   // Linux & friends arrive here:
   printf("connected\n");
   return 0;
}


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.

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

Re: connect() hangs on a listen()ing AF_UNIX socket

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

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:
> 
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <sys/un.h>
> 
> int main()
> {
>   sockaddr_un sa = {AF_UNIX, "testsocket"};
>   unlink(sa.sun_path);
> 
>   int sd1 = socket(AF_UNIX, SOCK_STREAM, 0);
>   if (sd1 < 0) {
>     perror("socket"); return 1;
>   }
>   if (bind(sd1, (sockaddr*) &sa, sizeof(sa))) {
>     perror("bind"); return 1;
>   }
>   if (listen(sd1, 10) < 0) {
>     perror("listen"); return 1;
>   }
> 
>   int sd2 = socket(AF_UNIX, SOCK_STREAM, 0);
>   if (sd2 < 0) {
>     perror("socket"); return 1;
>   }
>   printf("connecting to %s ...\n", sa.sun_path);
> 
>   // Cygwin hangs here:
>   if (connect(sd2, (sockaddr*) &sa, sizeof(sa))) {
>     perror("connect"); return 1;
>   }
> 
>   // Linux & friends arrive here:
>   printf("connected\n");
>   return 0;
> }
> 
> 
> 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 :(

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.

Would it help to patch postfix for Cygwin to use a local-only AF_INET
socket at this point instead?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: connect() hangs on a listen()ing AF_UNIX socket

[Christian Franke]

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

Re: connect() hangs on a listen()ing AF_UNIX socket

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]

On Aug 21 21:14, Christian Franke wrote:
> 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.

Yeah, that might be very tricky, especially if the executable forks and
execs after calling listen.

> >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.

Well, it's not *only* SO_PEERCRED.  Another, the older part of the
handshake, is about recognizing the peer.  Since AF_UNIX sockets don't
exist on Windows, Cygwin is using AF_INET sockets under the hood, and
so *any* Windows process could accidentally connect to a Cygwin AF_UNIX
socket.  The handshake also aims to avoid this scenario.  Only if the
handshake worked, the peers can be sure to talk to another Cygwin
process assuming an AF_UNIX socket.

A Cygwin-specific socket option which switches off the handshake would
disallow this peer recognition.  How bad is that?  I'm not sure.

Another potential solution might be to defer the AF_UNIX handshake to
the first send/recv:

Whatever the peers do, there is a certain protocol used.  That means,
there's an implicit understanding who's going to do the first send and
who's doing the first recv.  So, after connect/accept, both sides of the
sockets go into "connected_but_handshake_missing" mode.  On the first
send/recv, the handshake gets started and if it fails, send/recv
return ECONNRESET.

This might be easier to implement and might even get rid of the special
code in select handling the AF_UNIX handshake after a non-blocking
connect.  The potential problem here is that this might require another
set of changes to cover select...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: connect() hangs on a listen()ing AF_UNIX socket

[Christian Franke]

Corinna Vinschen wrote:
> On Aug 21 21:14, Christian Franke wrote:
>> ...
>> 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.
> Yeah, that might be very tricky, especially if the executable forks and
> execs after calling listen.

Which would require to pass an accept()ed handle from parent to 
(grand)child. Let's forget this option for now.


>>> 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.
> Well, it's not *only* SO_PEERCRED.  Another, the older part of the
> handshake, is about recognizing the peer.  Since AF_UNIX sockets don't
> exist on Windows, Cygwin is using AF_INET sockets under the hood, and
> so *any* Windows process could accidentally connect to a Cygwin AF_UNIX
> socket.  The handshake also aims to avoid this scenario.  Only if the
> handshake worked, the peers can be sure to talk to another Cygwin
> process assuming an AF_UNIX socket.
>
> A Cygwin-specific socket option which switches off the handshake would
> disallow this peer recognition.  How bad is that?  I'm not sure.

Good question.


> Another potential solution might be to defer the AF_UNIX handshake to
> the first send/recv:
>
> Whatever the peers do, there is a certain protocol used.  That means,
> there's an implicit understanding who's going to do the first send and
> who's doing the first recv.  So, after connect/accept, both sides of the
> sockets go into "connected_but_handshake_missing" mode.  On the first
> send/recv, the handshake gets started and if it fails, send/recv
> return ECONNRESET.

Is an actual handshake really required? It would possibly be sufficient 
that each peer sends its secret+credential and then expects a correct 
secret+credential from the other peer before sending anything.

After actual connect()/accept():

send our secret+cred (should not block due to TCP queuing).
if (! nonblocking recv peer secret+cred)
   set_state(connected_but_secret_missing)
else
   set_state(connected)


Before actual send()/recv()/getpeerid():

if (state == connected_but_secret_missing) {
   if (! recv peer secret+cred)
     abort_connection(ECONNRESET)
   else
     set_state(connected)
}


AFAICS this should provide the behavior required for postfix: client 
connect() succeeds before server accept().
It adds the following unusual behavior: client send() and getpeereid() 
wait for server accept().

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

Re: connect() hangs on a listen()ing AF_UNIX socket

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

On Aug 22 20:32, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Aug 21 21:14, Christian Franke wrote:
> >>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.
> >Well, it's not *only* SO_PEERCRED.  Another, the older part of the
> >handshake, is about recognizing the peer.  Since AF_UNIX sockets don't
> >exist on Windows, Cygwin is using AF_INET sockets under the hood, and
> >so *any* Windows process could accidentally connect to a Cygwin AF_UNIX
> >socket.  The handshake also aims to avoid this scenario.  Only if the
> >handshake worked, the peers can be sure to talk to another Cygwin
> >process assuming an AF_UNIX socket.
> >
> >A Cygwin-specific socket option which switches off the handshake would
> >disallow this peer recognition.  How bad is that?  I'm not sure.
> 
> Good question.
> 
> >Another potential solution might be to defer the AF_UNIX handshake to
> >the first send/recv:
> >
> >Whatever the peers do, there is a certain protocol used.  That means,
> >there's an implicit understanding who's going to do the first send and
> >who's doing the first recv.  So, after connect/accept, both sides of the
> >sockets go into "connected_but_handshake_missing" mode.  On the first
> >send/recv, the handshake gets started and if it fails, send/recv
> >return ECONNRESET.
> 
> Is an actual handshake really required? It would possibly be sufficient that
> each peer sends its secret+credential and then expects a correct
> secret+credential from the other peer before sending anything.
> 
> After actual connect()/accept():
> 
> send our secret+cred (should not block due to TCP queuing).

So both peers send their credentials...

> if (! nonblocking recv peer secret+cred)
>   set_state(connected_but_secret_missing)
> else
>   set_state(connected)

This will almost always result in connected_but_secret_missing.  It's
probably ok to drop the recv attempt here entirely.

> Before actual send()/recv()/getpeerid():
> 
> if (state == connected_but_secret_missing) {
>   if (! recv peer secret+cred)
>     abort_connection(ECONNRESET)
>   else
>     set_state(connected)
> }

Sounds like a nice idea.  We should try that.  I'm just not sure how
much time I have left to work on this before my vaca next month.  Do you
have fun to look into that?  We have waited so long for postfix, I guess
a couple more weeks won't really hurt.

Otherwise the easy solution you suggested before would be rather quickly
implemented...

> AFAICS this should provide the behavior required for postfix: client
> connect() succeeds before server accept().
> It adds the following unusual behavior: client send() and getpeereid() wait
> for server accept().

Same with recv.  Well, that might be unusual, but in most cases send
recv and getpeereid will be called after a connect/accept.  It's as
much a trade-off as the connect/accept requirement today.  As a resort
we'd still have the "easy" solution removing the credential exchange
entirely.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: connect() hangs on a listen()ing AF_UNIX socket

[Christian Franke]

Corinna Vinschen wrote:
> On Aug 22 20:32, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>
>>> Another potential solution might be to defer the AF_UNIX handshake to
>>> the first send/recv:
>>>
>>> Whatever the peers do, there is a certain protocol used.  That means,
>>> there's an implicit understanding who's going to do the first send and
>>> who's doing the first recv.  So, after connect/accept, both sides of the
>>> sockets go into "connected_but_handshake_missing" mode.  On the first
>>> send/recv, the handshake gets started and if it fails, send/recv
>>> return ECONNRESET.
>> Is an actual handshake really required? It would possibly be sufficient that
>> each peer sends its secret+credential and then expects a correct
>> secret+credential from the other peer before sending anything.
>>
>> After actual connect()/accept():
>>
>> send our secret+cred (should not block due to TCP queuing).
> So both peers send their credentials...
>
>> if (! nonblocking recv peer secret+cred)
>>    set_state(connected_but_secret_missing)
>> else
>>    set_state(connected)
> This will almost always result in connected_but_secret_missing.  It's
> probably ok to drop the recv attempt here entirely.

Agree.


>> Before actual send()/recv()/getpeerid():
>>
>> if (state == connected_but_secret_missing) {
>>    if (! recv peer secret+cred)
>>      abort_connection(ECONNRESET)
>>    else
>>      set_state(connected)
>> }
> Sounds like a nice idea.  We should try that.  I'm just not sure how
> much time I have left to work on this before my vaca next month.  Do you
> have fun to look into that?  We have waited so long for postfix, I guess
> a couple more weeks won't really hurt.

OK, will try that

Postfix apparently pushes Cygwin to its limits. With a test cygwin1.dll 
where the secret+cred exchange is fully disabled, postfix starts up but 
queuing of mail fails.

This is because fchmod() is called on a file rename()d after open():

fd = open("tempfile", ., 0600);
// use fd's inode number and current time to create unique "queuefile".
rename("tempfile", "queuefile");
write(fd, "SOME MAIL....", .);
fchmod(fd, 0700); // fails with ENOENT on Cygwin (because it does a 
chmod("tempfile",.)?)
close(fd);

A workaround using chmod("queuefile", 0700) helped here. Then smtp 
client, smtpd server (direct or via smarthost), sendmail emulation and 
local delivery to maildir works. Running as service with uid/gid 
switching is not tested yet.

It will likely take some time to look into all these details before 
first ITP.
(Therefore let's forget the "cygcheck -m" patch for now :-).

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

Re: connect() hangs on a listen()ing AF_UNIX socket

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

On Aug 26 21:03, Christian Franke wrote:
> Corinna Vinschen wrote:
> >Sounds like a nice idea.  We should try that.  I'm just not sure how
> >much time I have left to work on this before my vaca next month.  Do you
> >have fun to look into that?  We have waited so long for postfix, I guess
> >a couple more weeks won't really hurt.
> 
> OK, will try that

Cool!  Don't hesitate to discuss implementation details on the
cygwin-developers list.

> Postfix apparently pushes Cygwin to its limits. With a test cygwin1.dll
> where the secret+cred exchange is fully disabled, postfix starts up but
> queuing of mail fails.
> 
> This is because fchmod() is called on a file rename()d after open():
> 
> fd = open("tempfile", ., 0600);
> // use fd's inode number and current time to create unique "queuefile".
> rename("tempfile", "queuefile");
> write(fd, "SOME MAIL....", .);
> fchmod(fd, 0700); // fails with ENOENT on Cygwin (because it does a
> chmod("tempfile",.)?)
> close(fd);

I fixed that in CVS (and I'm just generating a snapshot).  The problem
was that the functions reading and writing security descriptors didn't
use the special "reopen by handle" semantics of the NtOpenFile call if
a reopen was necessary.  Rather they just tried to open the file by name
again, just with different open flags.  I fixed that, as well as another
occurence of the same problem when trying to read and write extended
attributes.

This won't work on filesystems which don't support reopen semantics,
which is Netapp and NWFS.  I have an idea how to workaround that for
these FSes, but that's not high priority.

> A workaround using chmod("queuefile", 0700) helped here. Then smtp client,
> smtpd server (direct or via smarthost), sendmail emulation and local
> delivery to maildir works. Running as service with uid/gid switching is not
> tested yet.
> 
> It will likely take some time to look into all these details before first
> ITP.
> (Therefore let's forget the "cygcheck -m" patch for now :-).

Ok, no worries there :)


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: connect() hangs on a listen()ing AF_UNIX socket

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> I fixed that in CVS (and I'm just generating a snapshot).  The problem
> was that the functions reading and writing security descriptors didn't
> use the special "reopen by handle" semantics of the NtOpenFile call if
> a reopen was necessary.  Rather they just tried to open the file by name
> again, just with different open flags.  I fixed that, as well as another
> occurence of the same problem when trying to read and write extended
> attributes.

The 2014-08-26 snapshot looks bad.  It seems that shebang processing doesn't
work anymore, reverting to the 2014-08-25 snapshot fixes that problem.


Regards,
Achim.


--
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

Re: connect() hangs on a listen()ing AF_UNIX socket

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

On Aug 27 08:57, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > I fixed that in CVS (and I'm just generating a snapshot).  The problem
> > was that the functions reading and writing security descriptors didn't
> > use the special "reopen by handle" semantics of the NtOpenFile call if
> > a reopen was necessary.  Rather they just tried to open the file by name
> > again, just with different open flags.  I fixed that, as well as another
> > occurence of the same problem when trying to read and write extended
> > attributes.
> 
> The 2014-08-26 snapshot looks bad.  It seems that shebang processing doesn't
> work anymore, reverting to the 2014-08-25 snapshot fixes that problem.

Fixed in CVS.  The idea to reopen the file by handle is still good.
*Iff* there is an open handle to the file to begin with...

I'm just creating a snapshot but this may take a few minutes longer
than anticipated due to connection problems.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: connect() hangs on a listen()ing AF_UNIX socket

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On Aug 27 11:50, Corinna Vinschen wrote:
> On Aug 27 08:57, Achim Gratz wrote:
> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > I fixed that in CVS (and I'm just generating a snapshot).  The problem
> > > was that the functions reading and writing security descriptors didn't
> > > use the special "reopen by handle" semantics of the NtOpenFile call if
> > > a reopen was necessary.  Rather they just tried to open the file by name
> > > again, just with different open flags.  I fixed that, as well as another
> > > occurence of the same problem when trying to read and write extended
> > > attributes.
> > 
> > The 2014-08-26 snapshot looks bad.  It seems that shebang processing doesn't
> > work anymore, reverting to the 2014-08-25 snapshot fixes that problem.
> 
> Fixed in CVS.  The idea to reopen the file by handle is still good.
> *Iff* there is an open handle to the file to begin with...
> 
> I'm just creating a snapshot but this may take a few minutes longer
> than anticipated due to connection problems.

Snapshot is up.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: connect() hangs on a listen()ing AF_UNIX socket

[Achim Gratz]

Corinna Vinschen writes:
>> Fixed in CVS.  The idea to reopen the file by handle is still good.
>> *Iff* there is an open handle to the file to begin with...
>> 
>> I'm just creating a snapshot but this may take a few minutes longer
>> than anticipated due to connection problems.
>
> Snapshot is up.

I failed to mention that this snapshot fixed the problem and has given
me no further grief in the latter half of the day.  :-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
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

Re: connect() hangs on a listen()ing AF_UNIX socket

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On Aug 27 19:57, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> Fixed in CVS.  The idea to reopen the file by handle is still good.
> >> *Iff* there is an open handle to the file to begin with...
> >> 
> >> I'm just creating a snapshot but this may take a few minutes longer
> >> than anticipated due to connection problems.
> >
> > Snapshot is up.
> 
> I failed to mention that this snapshot fixed the problem and has given
> me no further grief in the latter half of the day.  :-)

Glad to read that.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: connect() hangs on a listen()ing AF_UNIX socket

[Christian Franke]

Corinna Vinschen wrote:
> On Aug 26 21:03, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>> Sounds like a nice idea.  We should try that.  I'm just not sure how
>>> much time I have left to work on this before my vaca next month.  Do you
>>> have fun to look into that?  We have waited so long for postfix, I guess
>>> a couple more weeks won't really hurt.
>> OK, will try that
> Cool!  Don't hesitate to discuss implementation details on the
> cygwin-developers list.

Unfortunately, a very first prototype did not work. If receiving of 
secret+cred is delayed until first send()/recv(), postfix hangs in first 
send() after the connect(). During startup, the postfix master calls 
connect() and first client send() before corresponding server accept() 
is called.

So I decided to provide a intermediate solution for now, see:
https://cygwin.com/ml/cygwin-patches/2014-q3/msg00015.html

For the long term, this approach may work or not:
Remove the complete handshake over TCP. Maintain a table of current TCP 
connections in the socket "file". The table contains pid, TCP port and 
credentials for the server which did the (first) listen() call and for 
all connected clients. Some hashes could be added to check for validity.


>> Postfix apparently pushes Cygwin to its limits. With a test cygwin1.dll
>> where the secret+cred exchange is fully disabled, postfix starts up but
>> queuing of mail fails.
>>
>> This is because fchmod() is called on a file rename()d after open():
>>
>> fd = open("tempfile", ., 0600);
>> // use fd's inode number and current time to create unique "queuefile".
>> rename("tempfile", "queuefile");
>> write(fd, "SOME MAIL....", .);
>> fchmod(fd, 0700); // fails with ENOENT on Cygwin (because it does a
>> chmod("tempfile",.)?)
>> close(fd);
> I fixed that in CVS (and I'm just generating a snapshot).

Works with postfix.

Thanks,
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

Re: connect() hangs on a listen()ing AF_UNIX socket

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

On Sep 25 16:24, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Aug 26 21:03, Christian Franke wrote:
> >>Corinna Vinschen wrote:
> >>>Sounds like a nice idea.  We should try that.  I'm just not sure how
> >>>much time I have left to work on this before my vaca next month.  Do you
> >>>have fun to look into that?  We have waited so long for postfix, I guess
> >>>a couple more weeks won't really hurt.
> >>OK, will try that
> >Cool!  Don't hesitate to discuss implementation details on the
> >cygwin-developers list.
> 
> Unfortunately, a very first prototype did not work. If receiving of
> secret+cred is delayed until first send()/recv(), postfix hangs in first
> send() after the connect(). During startup, the postfix master calls
> connect() and first client send() before corresponding server accept() is
> called.

Yeah, that's tricky.  The handshake at send/recv time requires some
ordering which we can't enforce.  Too bad.

In theory, if the SO_PEERCRED stuff wouldn't be required for openssh,
we could really do without the handshake.  The peers are restricted to
the local machine anyway, and as with all communication, the peers have
to know the protocol.

> So I decided to provide a intermediate solution for now, see:
> https://cygwin.com/ml/cygwin-patches/2014-q3/msg00015.html

Thanks!  I'll look into it in the next couple of days.

> For the long term, this approach may work or not:
> Remove the complete handshake over TCP. Maintain a table of current TCP
> connections in the socket "file". The table contains pid, TCP port and
> credentials for the server which did the (first) listen() call and for all
> connected clients. Some hashes could be added to check for validity.

Yeah, we should try to come up with another technique.  Off the top of
my head I'm not sure if the above is feasible, but we should certainly
discuss this further.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]