unexpected EOF in read_timeout (was Re[2]: [Fwd: Re: meaning of "IO Error: skipping the delete...."]])

[tim.conway at philips.com]

I should have specified what i was replying to.  This section seemed to be 
in reference to what I had experienced before.
"
> Well, I'm stumped too.  (Although I thought I'd read that the
> default timeout was not infinite when not otherwise specified,
> but I've got so much going on right now that I could easily be
> confused on that one!)
> 
"

Tim Conway
tim.conway at philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn, 
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), 
".\n" '
"There are some who call me.... Tim?"




Dave Dykstra <dwd at bell-labs.com>
02/13/2002 12:20 PM

 
        To:     Tim Conway/LMT/SC/PHILIPS at AMEC
        cc:     rsync at lists.samba.org
        Subject:        Re: Re[2]: unexpected EOF in read_timeout (was Re[2]: [Fwd: Re: meaning of 
"IO Error: skipping the delete...."]])
        Classification: 



I'm not sure whether the SELECT_TIMEOUT issue is relevant to this thread 
or
another one, but it's good to know that you haven't seen the problem since
2.5.0 where Tridge put in a fix.  It is still waking up from select every
60 seconds, but it doesn't exit now if --timeout is 0.  I'm not sure why 
it
bothers wake up, but it goes to select again.

- Dave Dykstra

On Wed, Feb 13, 2002 at 09:40:30AM -0700, tim.conway at philips.com wrote:
> This is where it sets a sort of 60 second timeout if you don't set a 
> timeout at all.  As far as what it affects, I'm not that good with the 
> code.  I just know that my big syncs would die in almost exactly 1 
minute 
> unless I specified a timeout, and then would die at that timeout until i 

> got it very large.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> Tools at willy
> /users/Tools/encap/src/rsync-cvs>grep -i timeout *.c |grep -i select
> io.c:/* if no timeout is specified then use a 60 second select timeout 
*/
> io.c:#define SELECT_TIMEOUT 60
> io.c:           tv.tv_sec = io_timeout?io_timeout:SELECT_TIMEOUT;
> io.c:           tv.tv_sec = io_timeout?io_timeout:SELECT_TIMEOUT;
> Tools at willy
> /users/Tools/encap/src/rsync-cvs>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> I last tested and saw the problem with a 2.4.6 with a bunch of patches. 
> Apparently it's fixed, because my test last week (script below) ran for 
> 7.5h, (though when it finished, there were big differences in the trees, 

> which I sould have though would have been cleaned up).
> 
> Tim Conway
> tim.conway at philips.com
> 303.682.4917
> Philips Semiconductor - Longmont TC
> 1880 Industrial Circle, Suite D
> Longmont, CO 80501
> Available via SameTime Connect within Philips, n9hmg on AIM
> perl -e 'print pack(nnnnnnnnnnnn, 
> 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), 
> ".\n" '
> "There are some who call me.... Tim?"
> 
> 
> 
> 
> Rusty Carruth <rcarruth at tempe.tt.slb.com>
> Sent by: rsync-admin at lists.samba.org
> 02/13/2002 08:23 AM
> 
> 
>         To:     nitin.agarwal at timesgroup.com
>         cc:     rsync at lists.samba.org
> (bcc: Tim Conway/LMT/SC/PHILIPS)
>         Subject:        Re[2]: unexpected EOF in read_timeout (was 
Re[2]: [Fwd: Re: meaning of "IO 
> Error: skipping the delete...."]])
>         Classification: 
> 
> 
> 
> Nitin Agarwal <nitin.agarwal at timesgroup.com> wrote:
> > Dear Mr. Rusty,
> > We have not defined the timeout parameter in the configuration file. 
> That means no timeout (by
> > default). So, that cant be the solution.
> > Further, I checked on the net (in the mailing lists), many are 
> complaining the same error, but
> > none has given the solution for the same.
> > 
> > Kindly advice what to do......
> 
> Well, I'm stumped too.  (Although I thought I'd read that the
> default timeout was not infinite when not otherwise specified,
> but I've got so much going on right now that I could easily be
> confused on that one!)
> 
> I'm sending this reply to the entire list in hopes that I've simply
> missed the answer, or that someone knows the answer, or something...
> 
> rc