X-Spam-Check-By: sourceware.org
Message-ID: <a5f030530604270450p43f14467r3eaa7bd85dc5a611@mail.gmail.com>
Date: Thu, 27 Apr 2006 07:50:31 -0400
From: "Brett Serkez" <bserkez AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: rsync over ssh hang issue understood
In-Reply-To: <44508D05.307@baltech.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <061e01c6694d$18d79e20$a501a8c0 AT CAM DOT ARTIMI DOT COM> 	 <014001c66953$3eeded20$b5db87d4 AT multiplay DOT co DOT uk> 	 <e2ogj9$cnj$1 AT sea DOT gmane DOT org> 	 <01cc01c66968$50acb950$b5db87d4 AT multiplay DOT co DOT uk> 	 <e2okqi$sf9$1 AT sea DOT gmane DOT org> 	 <20060427081642 DOT GA11497 AT calimero DOT vinschen DOT de> 	 <44508D05 DOT 307 AT baltech DOT de>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id k3RBopMq009903

> If there is something I can do in order to narrow down the problem,
> please let me know. This issue has already been discussed on the rsync
> list (https://bugzilla.samba.org/show_bug.cgi?id=2957) and Wayne from
> the rsync project was quite sure about what he called the "Cygwin's
> pipe-data bug".

Yes, this is it.  Reading the above reference, the 2 processes refered
to on the Cygwin end are ssh and rsync, connected via a local pipe.

On a Linux/UNIX system the local rsync process would have inherited
the socket connected to the rsync process on the target and thus the
two rsync processes would be directly connected over the socket.  The
Windows environment (i.e., lack of a native fork/exec/inheritance)
requires the ssh process to remain involved as a middle man, passing
socket data to the local pipe and visa versa.  It appears to fail in
this capacity at some point, leaving both ends waiting for the other.

Just as a note, due to this issue, the issue with sshd/.cygrunsrv
utilizing 100% of the CPU on occasion, the ssh -X/-Y hang issue, and
slow bash startup with real-time virus/spyware detection active, I was
forced to find an alternative, I found OpenVPN.  Once two systems are
securely and privately connected, any protocol can be used, for
instance VNC (vs. X forwarding),  rsyncd (vs. rsync over ssh), direct
file system mounting and so on.  OpenVPN has reasonable, UNIX like
control so that the connection can be established on demand or
continuous as needed and can be routed over a single socket connection
like ssh, both OpenVPN and ssh ride over OpenSSL.

I've noticed that once Cygwin is removed from a given system, virus
scans, spyware scans and disk defragmention speed dramatically
improve.  I've not investigated, but I believe this is due to the
large number of small files in the Cygwin directory hierachy, which is
natural in a Linux/UNIX like environment.

I would have prefered to have used Cygwin, at this point it is all but
eliminted from production systems that I maintain as it has proven too
problematic, perhaps (I hope) this will change in the future.  I
continue to use Cygwin in my personal environment and follow this
list.

Brett

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/