That patch works perfectly. Thanks!
On Wed, May 18, 2005 at 04:36:55PM -0700, Wayne Davison wrote:
> On Wed, May 18, 2005 at 11:23:38AM -0500, Steve Sether wrote:
> > But it looks to me like last_io is reset on the sender side every
> > time it receives a packet (as well as when it sends a packet
On Wed, May 18, 2005 at 11:23:38AM -0500, Steve Sether wrote:
> But it looks to me like last_io is reset on the sender side every
> time it receives a packet (as well as when it sends a packet).
Ah yes -- how silly of me. Yes, that will prevent my patch from working
right. I was fooled into thin
I don't think it's the blocksize. I'm still not terribly familiar with
the inner workings of rsync, but from what I see maybe_send_keepalive() is
never sending a keepalive on the sender side. It looks like the test
in maybe_send_keepalive() is never passed. Right now that test is:
if (time(NULL)
On Sun, May 15, 2005 at 07:20:42PM -0500, Steve Sether wrote:
> Truly strange results. I tried --timeout=59 on the client side
> (which is what my server config is set to), and got identical results
> from before (timeout). I then tried a smaller value than what's
> specified on the server conf
Truly strange results. I tried --timeout=59 on the client side
(which is what my server config is set to), and got identical results
from before (timeout). I then tried a smaller value than what's
specified on the server config file, and it ran to completion.
Even specifying 58 seconds on the
On Sun, May 15, 2005 at 06:46:01AM -0500, Steve Sether wrote:
> I applied this patch to 2.6.5pre1 and recompiled both sides
> and am still getting the same error. My timeout is set to
> 59 seconds.
Hmm, it appears that your timeout is set in the server's config file,
not via the client's command
I applied this patch to 2.6.5pre1 and recompiled both sides
and am still getting the same error. My timeout is set to
59 seconds. Do you want strace output again?
On Sat, May 14, 2005 at 12:50:40PM -0700, Wayne Davison wrote:
> On Sat, May 14, 2005 at 12:28:20PM -0700, Wayne Davison wrote:
> >
On Sat, May 14, 2005 at 12:28:20PM -0700, Wayne Davison wrote:
> I'll attach a patch that you can try out with 2.6.5pre1 or the
> latest "nightly" tar file (or probably even 2.6.4 [...]
I was a little hasty with that patch -- the sender needs to use the
global allowed_lull var, otherwise maybe_sen
On Sat, May 14, 2005 at 12:08:44PM -0700, Wayne Davison wrote:
> So, it would be good to extend the keep-alive code to have the sender
> periodically spit out keep-alive packets to the receiver while it is
> busy reading the checksum data from the generator.
This turns out to be very easy -- I tes
On Fri, May 13, 2005 at 06:22:56AM -0500, Steve Sether wrote:
> I'm assuming that wouldn't help this bug, since my test is only
> sending one file.
Ahh, interesting. The keep-alive protection is currently only in the
generator, and it guards against long lulls that occur during the gaps
between f
> Maybe. You must be using at least 2.6.4 on both ends of the connection
> and not overriding the protocol version below 29. (You can see what
> protocol was negotiated by specifying at least four -v options.) If the
> remote system has multiple versions of rsync installed, perhaps it is
> runni
On Thu, May 12, 2005 at 04:43:55PM -0500, Steve Sether wrote:
> Now my understanding was that the keepalive feature was supposed to
> prevent this from ever happening.
Yes, that's certainly what it's supposed to prevent.
> Am I doing something wrong?
Maybe. You must be using at least 2.6.4 on b
I'm not sure keepalive is working the way I think it's supposed to.
Here's my test. I've got a large file (approx 1 gig) on the rsync
server, and I append a character on the end to make it slightly
different. I fire up rsync on the client side and everything
works fine until I hit the timeout val
13 matches
Mail list logo
