Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Date: Tue, 24 Sep 2002 19:29:40 +0900
From: Anthony Heading <aheading AT jpmorgan DOT com>
To: cygwin AT cygwin DOT com, rsync AT lists DOT samba DOT org
Subject: Re: 2.5.5-1 rsync hangs
Message-ID: <20020924102940.GA25046@tkd-fires-02.ja.jpmorgan.com>
References: <3D8F743E DOT C6D337EA AT real DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D8F743E.C6D337EA@real.com>
User-Agent: Mutt/1.4i

On Mon, Sep 23, 2002 at 01:06:22PM -0700, Sudheer Tumuluru wrote:
> 
>     I am having the same problem with rsync 2.5.5-1. I am
> trying to rsync a couple of short text files between a linux server and
> Win2k Professional boxes with cygwin. About 20% of the time, rsync freezes
> at the end of the transfer, and I can't kill the rsync process in
> cygwin even if I give it a 9 (SIGTERM) signal. This happens mostly on dual-processor
> machines but it did happen once on the single proc machine as well.

Me too.  I spent this afternoon debugging.  There doesn't appear to be
anything wrong with rsync - looks rather more like something in cygwin
signal delivery is ill.

In my case I'm trying to pull files onto Windows(XP) from Unix(Solaris).

rsync forks in this case; the parent process generates the filelisT
while a child process does the receiving.  (Something like that, at
least; I guess it's for deadlock avoidance)

At the end, the parent process waves farewell to the remote server,
and then does a kill(..., SIGUSR2) on the child pid to tell it to exit.

This signal seems to get lost, as suggested above, some moderate
percentage of the time.

The child process is supposedly waiting for this signal inside
msleep(), which calls select() to wait in 20ms bursts.  In the
cases that the child manages to reach the select() in time to
start waiting, I didn't observer any hangs.  But consistently
if the kill was received before that point, the child process
simply locks up. 

This suggests that hack workaround of adding a call to
say msleep(30) just before the line kill(pid, SIGUSR2) in
main.c:do_recv().  

With that kludge in, I haven't seen any hangs in a few hundred 
trials.  YMMV, but it might be a helpful bandaid until some
cygwin expert has the chance fix things properly. 

Rgds

Anthony









This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/