X-Spam-Check-By: sourceware.org
Message-Id: <1136685291.12195.251325082@webmail.messagingengine.com>
From: "Brett Serkez" <techie AT serkez DOT net>
To: "Ken Senior" <seniork AT gmail DOT com>
Cc: cygwin AT cygwin DOT com
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
References: <43BDAFBC DOT 9080401 AT gmail DOT com>    <1136506661 DOT 2833 DOT 251196190 AT webmail DOT messagingengine DOT com>    <43BDBBC2 DOT 1040100 AT gmail DOT com>    <1136509322 DOT 5881 DOT 251198868 AT webmail DOT messagingengine DOT com>    <43BDCD93 DOT 1060009 AT gmail DOT com>    <1136517852 DOT 14114 DOT 251205876 AT webmail DOT messagingengine DOT com>    <47d3786c0601070544u215f5d8arb5fe75723b7df86c AT mail DOT gmail DOT com>
Subject: Re: cygwin and rsync
In-Reply-To: <47d3786c0601070544u215f5d8arb5fe75723b7df86c@mail.gmail.com>
Date: Sat, 07 Jan 2006 20:54:51 -0500
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

<...snip...>
> Does this tell anyone anything?  If not, I could traverse the learning
> curve on getting gdb information from the process.

As a point of information, when rsync is run, as in this case using ssh,
it is using ssh to start a remote rsync on the server.  These two rsyncs
are able to communicate with each other because the standard in (stdin)
of each is connected to the standard out (stdout) of the other over the
network.  So althought there is buffering, each must read and write at
the appropriate times in a well understood sequence/protocol as other
wise they come out of sync and fail, most likely in a deadlock.

On the surface is *looks* like the problem is that the local rsync is
hanging on a write to stdout (descriptor 1 in your trace).  The
question is why. It is not clear to me if it has simply failed to fully
read all that the remote rsync needs to send and therefore there is in
a deadly embrace or the remote has exited and the socket wasn't
properly cleaned up.

As far as using gdb, rather than using the full rsync command line, use
the command 'gdb rsync' to start rsync in the debugger.  Then enter the
command 'run balance-of-rsync-command-line' and it should run normally.
Once it hangs, use control-c to break to the gdb command prompt and use
the command 'where' or 'bt' (back trace) to print a stack trace.

It would be very interested to log into the server and use ps to
locate the remote rsync during the run.  I don't know of this is an
option for you.  If so, you could see if the remote rsync has exited.
If not, you could attach to it using gdb and perform a stack trace,
presuming you could compile it with debug.  Kinda of a pain as you'd
have to either move it to /usr/bin or you could explicitly reference
the alternate copy in your Cygwin built rsync.  That is the local
rsync will build a command line to run rsync on the server via ssh
that depends on the path, but you could hard-code a path to your
debuggable rsync on the server.

Not sure how far you want to push this, I think this is going to take
some digging.

Brett
----------------------------------------------------------------
Brett C. Serkez, Techie



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