> I'm coming back to this issue, which I did not have time to
> go on further...
>
> One of the DSL lines has been ugpraded:
>
> Before = 5000/500
> Actual = 2/1000
[cut]
> The conclusion is, there seems to be a "fixed timeout" which
> happens at constant times. What can I do now? OK, I'
> All right, so it's a timeout. That means either the rsync
> protocol deadlocked (which would constitute a bug) or the
> network lost data. To determine which, please run all three
I'm coming back to this issue, which I did not have time to go on
further...
One of the DSL lines has been ug
On Mon, 2009-03-09 at 17:18 +0100, Boniforti Flavio wrote:
> Sorry, this should be the piece of information missing:
>
> Read from remote host remotehost.com: Connection timed out
>
> rsync: connection unexpectedly closed (236230676 bytes received so far)
> [receiver] rsync error: error in rsync
> You are missing rsync's output to stderr. There should be at
> a minimum "rsync error: error in rsync protocol data stream
> (code 12)", and probably a preceding error message that would
> give us an idea of what the problem is. Adjust your setup so
> you can capture the stderr, or if all e
On Mon, 2009-03-09 at 10:34 +0100, Boniforti Flavio wrote:
> > That is just the error code and its interpretation. What
> > error message comes prior to that?
>
> This is the whole log:
>
> /usr/bin/rsync -rtzv --port=8873 --delete --ignore-errors --numeric-ids
> \
> --delete-excluded --sta
> No, rsync's post-transfer checksum will catch the corruption,
> and rsync will redo the transfer. IOW, rsync is designed to
> recover from false block matches, except that false matches
> in a compressed transfer can cause a fatal error by throwing
> the -z protocol out of sync.
So, Matt, w
> That is just the error code and its interpretation. What
> error message comes prior to that?
This is the whole log:
/usr/bin/rsync -rtzv --port=8873 --delete --ignore-errors --numeric-ids
\
--delete-excluded --stats --progress localhost::Carlo/ \
/mnt/remote/Customer/daily.0/Carlo/
On Sun, 2009-03-08 at 14:48 +0200, Shachar Shemesh wrote:
> Wayne Davison wrote:
> >
> > We hypothesize that there can be an accidental match in the checksum
> > data, which would cause the two sides to put different streams of data
> > into their gzip compression algorithm, and eventually get out
Wayne Davison wrote:
We hypothesize that there can be an accidental match in the checksum
data, which would cause the two sides to put different streams of data
into their gzip compression algorithm, and eventually get out of sync
and blow up. If you have a repeatable case of a new file overwri
On Fri, Mar 06, 2009 at 08:20:43AM +0100, Boniforti Flavio wrote:
> I'm using "rsync -rtz" to transfer over an SSH tunnel and
> I always get
>
> 12 Error in rsync protocol data stream
That is just the error code and its interpretation. What error message
comes prior to that?
We hypothesize that
Hello there,
is it a known issue/problem with rsync transferring big files (let's say
over 0,5 GB)? I'm using "rsync -rtz" to transfer over an SSH tunnel and
I always get
12 Error in rsync protocol data stream
Any suggestions on how to solve this? Maybe removing "z" compression
could be helping?
11 matches
Mail list logo
