On 20.10.2016 03:24, Kip Warner wrote:
> I ended up giving up.
Me too.
I'm copying all files via 'scp' now - takes 3 days but no aborts or errors.
So I am very sure the problem is somewhere in rsync.
Bernd
--
Bernd Hohmann
Organisationsprogrammierer
Höhenstrasse 2 * 61130 Nidderau
Telefon: 0
On Tue, 2016-10-18 at 08:36 +0200, Paul Slootman wrote:
> Try the transfer without -z.
>
> Paul
I ended up giving up. What I did was I just removed the 30GB file
(which I really didn't need anyways) and the transfer carried on
without a hitch.
--
Kip Warner -- Senior Software Engineer
OpenPGP e
On 19.10.2016 21:46, devz...@web.de wrote:
> what does lsof tell? does rsync hang on a specific file?
Nothing. I ruled this out already.
> i would wonder if this is a rsync problem. as you told you killed all
> processes.
> so, on the second run rsync knows nothing from before...
Maybe somethin
what does lsof tell? does rsync hang on a specific file?
i would wonder if this is a rsync problem. as you told you killed all
processes.
so, on the second run rsync knows nothing from before...
roland
Am 18. Oktober 2016 12:08:00 MESZ, schrieb Bernd Hohmann
:
>On 18.10.2016 07:03, Kip Warn
On 18.10.2016 07:03, Kip Warner wrote:
> From what I can tell, there are no hardware problems. I also ran fsck
> on the drive. The machine seems to be fine.
I can confirm the problem.
Situation here: 2 identical HP Microservers (Debian 7, on site compiled
rsync 3.1.2, connected via OpenVPN).
SS
Try the transfer without -z.
Paul
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>> Have you tried performing a copy to a known good local device? If a
>> local copy fails, then I would start checking the file system of the
>> source and also the hardware of that system.
>
> That's a good idea. I just tried that and it copied no problem.
Do you have another system you could
On Sat, 2016-10-15 at 19:54 -0700, Kip Warner wrote:
> ...and apparently the second rsync server side process is
> actually
> still performing reads and writes more than an hour after the
> connection died...
>
> ...
> read(1,
> "\337\363\356\1^\26L\316\17\31izD\254\27\346\267\
On Thu, 2016-10-13 at 20:08 -0400, Kevin Korb wrote:
> I don't remember whether or not you said you were running rsync over
> ssh but if you are you can also debug the ssh layer. You can even do
> it at both ends
>
> On the server run a debugging sshd on an alternate port with:
> /usr/sbin/ss
On Thu, 2016-10-13 at 20:08 -0400, Kevin Korb wrote:
> I don't remember whether or not you said you were running rsync over
> ssh but if you are you can also debug the ssh layer. You can even do
> it at both ends
Yes, I'm doing this over an SSH tunnel.
> On the server run a debugging sshd on
On Thu, 2016-10-13 at 10:09 +0100, Dave Howorth wrote:
> Have you tried excluding the problem file from the transfer?
Hey Dave. All the other files appear to sync, up until it gets to that
one large file. Then it stalls, and finally times out. I could tell it
to exclude that important file, but th
I don't remember whether or not you said you were running rsync over ssh
but if you are you can also debug the ssh layer. You can even do it at
both ends
On the server run a debugging sshd on an alternate port with:
/usr/sbin/sshd -dDp222
(note that this will only accept 1 connection, debug t
On Wed, Oct 12, 2016 at 8:30 PM, Kip Warner wrote:
> I think the key insight was in the strace log which showed the
> select() call was timed out.
No, that's totally expected. While select() is waiting for I/O to arrive,
it returns to rsync every 60 seconds to allow it to decide if it wants to
On 2016-10-10 17:24, Kip Warner wrote:
Note that I have temporarily disabled timeouts and added extra
verbosity. The transfer to the remote host via SSH works fine, up until
it gets to a 30+ GB file (a VM image). It gets about 90+ percent of the
way through, hangs, and then times out.
I have a
On Wed 12 Oct 2016, Kip Warner wrote:
>
> I think the key insight was in the strace log which showed the select()
> call was timed out. If I knew what type of file descriptor it was being
> fed, I might have a clue. It might have been a socket or something on
> disk. I don't know.
You can use lso
On Wed, 2016-10-12 at 08:36 +0200, Paul Slootman wrote:
> As always it's best to first upgrade to the current version (3.1.3)
> if at all possible, as there's always the chance that the cause of
> your problems has already been fixed.
Good call, but I believe I may have ruled this out. I didn't up
On Wed, 2016-10-12 at 13:30 +1300, Henri Shustak wrote:
> Have you tried performing a copy to a known good local device? If a
> local copy fails, then I would start checking the file system of the
> source and also the hardware of that system.
That's a good idea. I just tried that and it copied n
On Mon 10 Oct 2016, Kip Warner wrote:
>
> The server the data is being uploaded to with the strace running on it
> has rsync version:
>
> $ rsync --version
> rsync version 3.0.9 protocol version 30
>
> The client reported:
>
> $ rsync --version
> rsync version 3.1.1 protocol
. On the client side I see the
following:
...
rsync: connection unexpectedly closed (3542035 bytes received so far)
[sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call
exit(255)
On
. On the client side I see the
following:
...
rsync: connection unexpectedly closed (3542035 bytes received so far)
[sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call
exit(255)
On
OK, I'm feeling stupid. I was pouring over the rsyncd.conf man page and there
was no discussion of filter rules, so I was guessing based on the
"filter" clause
description, not the "FILTER RULES" section of rsync.1. Really sorry.
Much clearer now...
On Tue, Mar 23, 2010 at 5:25 PM, Matt McCu
On Tue, 2010-03-23 at 17:12 -0700, Bruce Korb wrote:
> Fixing a spelling error for the log file name gets me the log text,
> but not anything I understand:
>
> Unknown filter rule: `/gdoc/***'
>
> OK, I am trying to ensure that files pushed to the "doc" module all start
> with the prefix "/gdoc/
Fixing a spelling error for the log file name gets me the log text,
but not anything I understand:
Unknown filter rule: `/gdoc/***'
OK, I am trying to ensure that files pushed to the "doc" module all start
with the prefix "/gdoc/". My reading of the docs seems to say to me that
this is the way
On Tue, 2010-03-23 at 17:05 -0700, Bruce Korb wrote:
> On Tue, Mar 23, 2010 at 4:59 PM, Matt McCutchen
> wrote:
> > On Tue, 2010-03-23 at 16:54 -0700, Bruce Korb wrote:
> >> I now have an strace output file. It opens rsyncd.conf correctly
> >> and reads in all the data in one gulp. I've trimmed
On Tue, 2010-03-23 at 16:54 -0700, Bruce Korb wrote:
> I now have an strace output file. It opens rsyncd.conf correctly
> and reads in all the data in one gulp. I've trimmed the strace to start from
> there. Notice that it tries to open the log file and fails because it
> isn't found.
That fail
Hi Matt,
On Tue, Mar 23, 2010 at 4:23 PM, Matt McCutchen wrote:
> "Yes" is the default, so you have to explicitly write "use chroot = no".
Done. No effect.
> --rsync-path='strace -f -o ~/rsync.strace rsync' to the client.
I now have an strace output file. It opens rsyncd.conf correctly
and r
On Tue, 2010-03-23 at 16:18 -0700, Bruce Korb wrote:
> does the "-e ssh" invocation of rsync actually load up rsyncd.conf ?
The double-colon source or destination path indicates the use of an
rsync daemon (which uses an rsyncd.conf file). The explicit "-e ssh"
tells the client to invoke the daemo
On Tue, 2010-03-23 at 16:15 -0700, Bruce Korb wrote:
> On Tue, Mar 23, 2010 at 3:57 PM, Matt McCutchen
> wrote:
> >> $ ls -l
> ...
> >> -rw-r--r-- 1 root root 2451 2010-03-23 15:30 log.txt
>
> Oops. Fixed. Still root owned, but mode is now 0666.
>
> > Ah. You have "use chroot
does the "-e ssh" invocation of rsync actually load up rsyncd.conf ?
If not, that would explain why no logging. H. Maybe I need
to work out a daemon over ssh tunnel now?
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://li
Hi Matt,
Thank you again.
On Tue, Mar 23, 2010 at 3:57 PM, Matt McCutchen wrote:
>> its 873 port -- as long as it will use a secure encrypted tunnel.
>
> The rsync daemon protocol on port 873 does not support encryption or
> integrity protection, so an rsync daemon over ssh may actually be just
On Tue, 2010-03-23 at 15:50 -0700, Bruce Korb wrote:
> Without the "-e ssh" I was getting no response at all. tcpdump wasn't showing
> any port 873 packets, but port 22 was getting through the vyatta virtual
> switch.
> So, "-e ssh", though I'd actually like to get the daemon working
> correctly
>> file_struct_len=16, extra_len=4
>> opening connection ....
>> note: iconv_open("UTF-8", "UTF-8") succeeded.
>> sending daemon args: ..
>> rsync: connection unexpectedly closed (0 byes received so far) [sender]
>> [sender] _exit_cleanup(code=1
8", "UTF-8") succeeded.
> sending daemon args: ..
> rsync: connection unexpectedly closed (0 byes received so far) [sender]
> [sender] _exit_cleanup(code=12, file=.../io.c, line=601): about to call
> exit(12)
>
> Yet this works correctly:
>
> rsync -v -e
p; copying disabled.) Anyway:
$ rsync -vv -a -e ssh --recursive gdoc rsync-a...@99.99.99.99::doc
file_struct_len=16, extra_len=4
opening connection
note: iconv_open("UTF-8", "UTF-8") succeeded.
sending daemon args: ..
rsync: connection unexpectedly closed (0 byes received
dhtmldude wrote:
I'm using Rsync 3.1.0 and VanDyke VShell for SSH.
Is there a reason why you are using the VD VS when you likely have
cygwin's 'ssh' built in as well? Cygwin's ssh was ~20-30% faster than
VD's technology (I benched it against their VSH/VCP tools in their
SecCRT package,
ase for key 'C:\cms\PageGenerator\qa_rsa':
nasad...@10.243.101.218's password:
exec request failed on channel 0
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
_exit_cleanup(code=12, file=io.c, line=609): entered
rsync error: unexplained error (code 255) at io.c(609) [send
On Sun, 2008-02-17 at 04:16 -0600, chuang liu wrote:
> I did a few more tests, and found some strange behaviors of rsync. If I
> put the address rsync://URL in the src, rsync works fine. But if I put it
> as the destination, rsync fails. If I use another format
> :: for the destination, rsync works
On Sun 17 Feb 2008, chuang liu wrote:
>
> I used a very old rsync (version 2.5.4, prototocl version 26). Is this a
> known issue with this version? Did I use rsync incorrectly? Thanks.
Even if it's not a known issue with that version, do you think anyone is
going to take the time to try and fix t
:34913/silo/t4.dat
rsync: Unknown host
rsync: connection unexpectedly closed (0 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(151)
bash-2.05a$ rsync -v --port=34913 what.dat 10.46.62.130::silo/t4.dat
\what.dat
wrote 119 bytes read 63 bytes 364.00 bytes
to get rsync work through firewall?
>
> When I tried the transfer, I got the following error messages.
>
> my command:
> rsync -a --copy-links localfile rsync:://me@ IP>://test.dat
>
> In the client side, the error messages are
>
> rsync: Unknown host
> rsync: co
got the following error messages.
my command:
rsync -a --copy-links localfile rsync:://me@://test.dat
In the client side, the error messages are
rsync: Unknown host
rsync: connection unexpectedly closed (0 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(151
https://bugzilla.samba.org/show_bug.cgi?id=3492
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=3646
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=3646
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|rsync: connection |rsync: connection
https://bugzilla.samba.org/show_bug.cgi?id=3646
Summary: rsync: connection unexpectedly closed (3207118 bytes
received so far) [generator]
Product: rsync
Version: 2.6.6
Platform: x86
OS/Version: Linux
Status: NEW
>
> On Fri, Mar 17, 2006 at 06:05:11PM +0100, Dag Wieers wrote:
> > Maybe it's useful to link to 3rd party rsync packages from
> the rsync
> > website ?
>
> Yeah, I think this would be a good idea. I've added a link
> to your RPMs
> to the newly improved download page:
>
> http://rsync.s
On Fri, Mar 17, 2006 at 06:05:11PM +0100, Dag Wieers wrote:
> Maybe it's useful to link to 3rd party rsync packages from the rsync
> website ?
Yeah, I think this would be a good idea. I've added a link to your RPMs
to the newly improved download page:
http://rsync.samba.org/download.html
I
On Fri, 17 Mar 2006, Dag Wieers wrote:
> On Thu, 16 Mar 2006, C.Jagadish wrote:
>
> > Dear Mr. Samir,
> >
> > We are using RedHat 7.2. We are getting same error as reported by you some
> > time back (given below).
> >
> > Did you get any solution?
>
> You may want to update your rsync versio
On Thu, 16 Mar 2006, C.Jagadish wrote:
> Dear Mr. Samir,
>
> We are using RedHat 7.2. We are getting same error as reported by you some
> time back (given below).
>
> Did you get any solution?
You may want to update your rsync version to something newer. Error output
has been improved and it
to the following:
[root at myhost_name root]# /usr/bin/rsync -va 10.0.8.190:usr/local/src
/local_folder
I got the following error:
Couldn't get address for your host (10.0.8.53)
rsync: connection unexpectedly closed (0 bytes read so far)
rsync error: error in rsync protocol data stream (co
On Fri, Feb 24, 2006 at 12:07:05PM +0530, Vijay Ram.C wrote:
> rsync: connection unexpectedly closed (1804855 bytes received so far)
> [receiver]
> rsync: connection unexpectedly closed (39 bytes received so far)
> [generator]
>
> The rsync command line
unexpectedly closed
(1804855 bytes received so far) [receiver]
rsync: connection unexpectedly closed
(39 bytes received so far) [generator]
The rsync command line is given as
below:
rsync
--timeout=60 srcIp::path/file.tar.gz
destPath/destFile
On looking into
https://bugzilla.samba.org/show_bug.cgi?id=3492
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from [EM
https://bugzilla.samba.org/show_bug.cgi?id=3492
Summary: rsync: connection unexpectedly closed (24 bytes read so
far)
Product: rsync
Version: 2.6.7
Platform: Other
OS/Version: HP-UX
Status: NEW
Severity
On Thu, Jul 14, 2005 at 10:47:24AM +0200, Francesco Andrisani wrote:
> Jul 14 09:12:51 vna009 rsyncd[21139]: rsync: connection unexpectedly closed
> (0 bytes read so far)
> Jul 14 09:12:51 vna009 rsyncd[21139]: rsync error: error in rsync protocol
> data stream (code 12) at io.
Hi all,
in my log file (/var/log/messages) I see two error lines.
I don’t know their explained:
Jul 14 09:12:51 vna009 rsyncd[21139]: rsync:
connection unexpectedly closed (0 bytes read so far)
Jul 14 09:12:51 vna009 rsyncd[21139]: rsync error:
error in rsync protocol data stream
On Mon, Jun 20, 2005 at 02:01:13PM +0300, Samir Noshy wrote:
> Couldn't get address for your host (10.0.8.53)
This error is coming from the remote shell -- you need to figure out how
to fix it. One way to start is to run rsync with two -v options, note
the remote-shell command it is running, and
rsync: connection unexpectedly closed (0
bytes read so far)rsync error: error in rsync protocol data stream (code 12)
at io.c(150)
Note: rsync
is working fine with the -e ssh option.
Also the rsh
and rlogin works fine in my host.
Any Advice
will be very helpful.
Best Regards.
Samir
Noshy
-
rsync: connection unexpectedly closed (0
bytes read so far)rsync error: error in rsync protocol data stream (code 12)
at io.c(150)
Note: rsync
is working fine with the -e ssh option.
Also the rsh
and rlogin works fine in my host.
Any Advice
will be very helpful.
Best Regards.
Samir Noshy
-
2129660 bytes read 225836 bytes total
>size -2005091632
>2003/10/14 11:25:07 [11256] rsync: connection unexpectedly closed (225836
>bytes read so far)
>2003/10/14 11:25:07 [11256] rsync error: error in rsync protocol data
>stream (code 12) at io.c(165)
>
>2003/10/14 12:01:28
> Hi rsync list,
>
> Im trying to use rsync to sync about 23GB over a local LAN.
> I use 2.5.6 compiled on SCO OpenServer 5.0.6, this is the command I use:
>
> rsync --verbose --stats --recursive --times --perms --links --delete
> eurux02::user2
I missed the destination filesystem when re-typing.
2003/10/14 11:25:07 [11256] rsync: connection unexpectedly closed (225836
bytes read so far)
2003/10/14 11:25:07 [11256] rsync error: error in rsync protocol data
stream (code 12) at io.c(165)
2003/10/14 12:01:28 [11693] rsync on user2 from eurux03 (192.168.100.3)
2003/10/14 12:22:31 [11693] wrote
On Wed, Jun 25, 2003 at 01:03:43AM +0800, [EMAIL PROTECTED] wrote:
> jw schultz wrote:
>
> >On Sun, Jun 22, 2003 at 11:12:56PM +0800, [EMAIL PROTECTED] wrote:
> >
> >
> When I sync'ed against other servers, my rsync client process always
> ran without --compress. Nevertheless, I've trie
yncs with -z, and lo and
behold, he was right and that sync worked..
Whereas on my client, it shows something like this (this clip not taken
from the same session, but likely to be similar).
[snip]
x11-wm/xpde/xpde-0.3.0.ebuild is uptodate
generate_files phase=1
rsync: connection unexpe
t;x11-wm/xpde/xpde-0.3.0.ebuild is uptodate
>generate_files phase=1
>rsync: connection unexpectedly closed (1657342 bytes read so far)
>rsync error: error in rsync protocol data stream (code 12) at io.c(165)
>_exit_cleanup(code=12, file=io.c, line=165): about to call exi
ild is uptodate
generate_files phase=1
rsync: connection unexpectedly closed (1657342 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(165)
_exit_cleanup(code=12, file=io.c, line=165): about to call exit(12)
rsync: connection unexpectedly closed (1493478 by
generate_files phase=1
>recv_files(metadata/timestamp)
> recv mapped metadata/timestamp of size 29
>metadata/timestamp
>rsync: connection unexpectedly closed (1494175 bytes read so far)
>rsync error: error in rsync protocol data stream (code 12) at io.c(
11-wm/xpde/xpde-0.3.0.ebuild is uptodate
generate_files phase=1
recv_files(metadata/timestamp)
recv mapped metadata/timestamp of size 29
metadata/timestamp
rsync: connection unexpectedly closed (1494175 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) a
some machines, I get an error
> similar to the following:
>
>rsync: connection unexpectedly closed (1491993 bytes read so far)
>rsync error: error in rsync protocol data stream (code 12) at io.c(165)
>rsync: connection unexpectedly closed (1491973 bytes read so far)
>
64-bit files, socketpairs, hard links, symlinks,
batchfiles,
IPv6, 64-bit system inums, 64-bit internal inums
Very frequently when rsync'ing with some machines, I get an error
similar to the following:
rsync: connection unexpectedly closed (1491993 bytes read so far)
Dave Dykstra <[EMAIL PROTECTED]> writes:
> There were a lot of bugs in rsync 2.4.6 in those areas; upgrade to
> 2.5.5 first.
Thanks, Dave! That solved all my problems. I guess I should've
upgraded before I sent the first email. I've learned my lesson.
Erik.
--
To unsubscribe or change optio
same error with ::tmp and ::tmp-open.]
>
> This is what rsync on box2 exits with:
>
> opening tcp connection to box1 port 873
> rsync: connection unexpectedly closed (12 bytes read so far)
> rsync error: error in rsync protocol data stream (code 12) at io.c(150)
> _exit_clea
error with ::tmp and ::tmp-open.]
This is what rsync on box2 exits with:
opening tcp connection to box1 port 873
rsync: connection unexpectedly closed (12 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(150)
_exit_cleanup(code=12, file=io.c, line=150
73 matches
Mail list logo
