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, [EMAIL PROTECTED] 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@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@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 > [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 02/13/2002 08:23 AM > > > To: [EMAIL PROTECTED] > cc: [EMAIL PROTECTED] > (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 <[EMAIL PROTECTED]> 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
