X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-0.0 required=5.0 tests=BAYES_20,SPF_HELO_PASS,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
connect():	No such file or directory
From:	Chris Dunlop <chris AT onthe DOT net DOT au>
Subject:	Re: cygwin + rsync issue under Windows 7 x64
Date:	Tue, 4 May 2010 06:58:34 +0000 (UTC)
Lines:	47
Message-ID:	<loom.20100504T085046-531@post.gmane.org>
References:	<4B8440BF DOT 8050403 AT cs DOT umass DOT edu> <733654e31003060921mca36c77j154e5af4440c568a AT mail DOT gmail DOT com> <20100308051951 DOT GB24024 AT shareable DOT org>
Mime-Version:	1.0
User-Agent:	Loom/3.14 (http://gmane.org/)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Jamie Lokier <jamie <at> shareable.org> writes:
> Wayne Davison wrote:
>>    I'd imagine that both ssh and rsync start using a lot of CPU because
>>    the socketpair must be indicating that it is ready for a write (or
>>    read) but the actual write() (or read()) fails to return any bytes (as
>>    long as errno is something like EAGAIN, EINTR, or EWOULDBLOCK, rsync
>>    will try again). ý If you want to test that theory, you could add some
>>    prints to rsync's io.c file near the 3 uses of EWOULDBLOCK and have it
>>    output what errno it gets. ý If you get that fixed, the programs that
>>    interface with a socketpair should go back to normal.
> 
> It would not be the first time Cygwin did something like that.
> 
> 11.5 years ago, Cygwin32 b19.1, I found it returning EAGAIN
> continuously when reading from pipes to a child process and from the
> master side of a pty to a child process, while select() indicated
> "ready for exception" (at least from the pty master; I don't remember
> if it was that or "ready for read" from a pipe).
> 
> How interesting that sockpair() now looks like having a similar problem.
> 
> Perhaps the sockpair problem might be related to the getting stuck
> people occasionally report with rsync + ssh + Cygwin ?  I.e. maybe
> disabling socketpair() will fix the stuck problem too?
> 
> Maybe the next time someone encounters it, they'll google this thread,
> try it and let us know how it went, thanks :)

...or they can try upgrading to cygwin-1.7.2-2 (or newer, assuming
cygwin's socket handling doesn't break again!).  From the release notes
(http://cygwin.com/ml/cygwin-announce/2010-03/msg00018.html):

   - Fix some hangs and a potential crash using pipes and FIFOs.
   - Fix multiple socket problems:
      - Potential blocking of non-blocking sockets.
      - Non-working renaming of AF_UNIX socket files.
      - Using MSG_PEEK on UDP sockets leads to data loss.

At least, that "fixed it for me"!:

http://article.gmane.org/gmane.network.rsync.general/22260


Cheers,

Chris



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

- Raw text -