On Tue, Feb 27, 2001 at 02:57:40PM -0600, Dave Dykstra wrote:
>
> Those symptoms are quite different. I suggest checking the server side
> logs first. The EOF occurs on the client side anytime the server side goes
> away prematurely. You probably aren't yet stressing TCP because I don't
> thin
On Tue, Feb 27, 2001 at 03:01:38PM -0500, Scott Russell wrote:
> All -
>
> I understand the focus of the discussion below is Linux <-> Solaris time
> outs but is anyone else seeing the same problem under Linux <-> Linux when
> running 2.4.6 rsync --deamon?
>
> Currently I'm seeing it from the cl
I see the same problem on a linux box running without any network
involved. rsync -av dir1 dir2. (where dir[12] are both on local ide
disks)
I posted a few weeks ago regarding my 2.4.6 hang -- (not running
--deamon)
http://lists.samba.org/pipermail/rsync/2001-January/003552.html.
I found two '
All -
I understand the focus of the discussion below is Linux <-> Solaris time
outs but is anyone else seeing the same problem under Linux <-> Linux when
running 2.4.6 rsync --deamon?
Currently I'm seeing it from the client end. Both of the servers I'm pulling
from were updated to 2.4.6 and then
Re: http://lists.samba.org/pipermail/rsync/2001-February/003628.html
Some more email was exhanged the last couple days on the subject of a TCP
hang between Solaris and Linux:
> Date: Mon, 26 Feb 2001 12:06:08 -0600
> From:
Here's a followup on the problem I was having hangs between an rsync 2.4.6
daemon on Linux 2.2.18pre17 (and others) and Solaris 2.7 (and others).
My last definitive post on this is in the rsync archive at
http://lists.samba.org/pipermail/rsync/2000-October/003004.html
I finally found how to r
On Fri, Oct 27, 2000 at 11:09:56AM -0500, Dave Dykstra wrote:
> Thanks. I went ahead and put it all into a tarball so you can get it
> conveniently through http as well. The URL is
> http://www.bell-labs.com/wwexptools/rsynctst/rsynctstdata.tar.gz
>
>
> > How big is that tree?
> >
> > e
On Fri, Oct 27, 2000 at 08:01:34AM -0600, Eric Whiting wrote:
> At work I'm behind a firewall that won't let me to the rsync port.
>
> I'm logged into my cable modem and I'll rsync it to my house, tar it
> up, ftp it to work and then I'll try different tests here.
Thanks. I went ahead and put
On Tue, Oct 24, 2000 at 04:57:05PM -0500, Dave Dykstra wrote:
> > On Fri, Oct 20, 2000 at 10:44:04AM +1000, Andrew Tridgell wrote:
> > ...
> > > Stephen tells me that a patch went into the 2.2.17 Linux kernel that
> > > was supposed to fix this particular problem. If you get a chance it
> > > woul
Here's a quick analysis of the tcpdump that Dave Dykstra just sent out.
There seems to be a couple of (possibly unrelated) problems.
On line 2066, static acks 69041, so on line 2067, dynamic sends
out 69041:69628. Static should ack this, but it never does, so
dynamic just keeps retrying that b
On Fri, Oct 20, 2000 at 04:26:49PM -0500, Dave Dykstra wrote:
> Andrew Tridgell wrote:
> > Dave Dykstra wrote:
> > > The linux server says
> > >
> > > Proto Recv-Q Send-Q Local Address Foreign Address State
> > > tcp35230 40686 expbuild.research.:8664 dynamic.ih.lu
It is time to recompile rsync with -g and wait for another hang.
eric
(gdb) attach 17407
Attaching to process 17407
(no debugging symbols found)...done.
0xff215d08 in _poll ()
(gdb) n
Single stepping until exit from function _poll,
which has no line number information.
0xff1ce6dc in select ()
(
Use lsof instead of pfiles if you have lsof available.
I have a version of strace for Solaris 2.6 that I fixed to grok socket
calls. It doesn't grok *64() calls, unfortunately, but I will someday
fix it to do so. It's not in any shape that cna be contributed back to
the strace project and it's r
More info/questions: (hung rsync is 17407)
# /usr/proc/bin/pstack 17407
17407: /usr/local/bin/rsync -rptgoD --partial --delete-after -vv
--delete -e
ff215d08 poll (ffbefad0, 0, 14)
ff1ce6d4 select (ffbefad0, ff2369f4, ff2369f4, ff2369f4, ff2369f4,
0) + 298
0001b568 msleep (14, ffbef
Eric,
Since the poll is nfds=0 and timeo=20 (i.e. almost certainly
msleep(20)) and since waitpid is looking for 17408, this actually
really has to be the call of wait_process() at main.c:532 where rsync
is (apparently) waiting for ssh to die.
The reason that timeout has no effect is that only i
> "Eric" == Eric Whiting <[EMAIL PROTECTED]> writes:
Eric> Forgot to say that I love rsync. :) I don't mean to sound
Eric> like a complainer or rsync-grump. I'm just trying to help
Eric> out a little bit. All these reports of problems are not
Eric> show-stoppers and only seem
16 matches
Mail list logo
