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
Hi Libor!
Thanks for your hint!
In fact using rsync via ssh as workaround *does work for me*, too.
This indeed adds an extra performance penalty for the SSH tunneling, but
in my final setup SSH will be required anyways.
In fact this issue seems to occur mainly with slow rsync servers like
N
Hello,
i was dealing with same thing , I coudln't find a sollution using rsyncd.
Using rsync+ssh did the trick ...
Problem was (probably) with slow NAS, taking ages to compute (initial?)
checksums of target file.
When using --progress or --verbose, it was just sitting there without output,
but s
I can't believe it -- but I DO fiddle around with _wireshark_ to get my
_backup_ done. Strange age of the 21th century.
Ok - here is what I was able to observe: At first everything seems to be
fine. After handshake the rsyncd is continuously sending every 1.7s
packets to the client which the c
-boun...@lists.samba.org] On
Behalf Of Justin T Pryzby
Sent: Friday, October 12, 2012 3:58 PM
To: rsync@lists.samba.org
Subject: Re: Problem rsyncing 450GB file to my NAS: 'connection unexpectedly
closed'
You can tcpdump it to see which side is closing the connection. My
understanding is that &quo
) [receiver=3.0.7]
> 2012/10/12 19:36:06 [7325] [receiver] _exit_cleanup(code=30,
> file=io.c, line=137): about to call exit(30)
> 2012/10/12 19:36:06 [7325] rsync: connection unexpectedly closed
> (322 bytes received so far) [generator]
> 2012/10/12 19:36:06 [7325] [generator] _exi
] [receiver] _exit_cleanup(code=30, file=io.c,
line=137): about to call exit(30)
2012/10/12 19:36:06 [7325] rsync: connection unexpectedly closed (322
bytes received so far) [generator]
2012/10/12 19:36:06 [7325] [generator] _exit_cleanup(code=12, file=io.c,
line=601): entered
2012/10/12 19:36:06 [7325
Wow: Thanks for your fast responses, Justin and Karl!
Yet the NAS is still located in my home network. So the network
connection shouldn't be the problem.
The pointer to the --inplace argument was really helpful. This is what I
really wanted in this particular use case.
I also tried to enab
On 10/12/2012 01:06:03 PM, Justin T Pryzby wrote:
> It sounds like a daemon may be timing out; is there a timeout
> specified in rsyncd.conf? Is there a remote logfile with any useful
> content?
I've gotten a 12 error code when a lame firewall broke the connection.
Karl
Free Software: "You d
mRCfj,*,2)
> [sender]
> make_file(storage/O4tK1PXwyelx8Oju,1sC-xfRUYg5cnMrPxeo5FTpE-AEM-,*,2)
> send_files starting
> send_files(3,
> /srv/encfs-mirrors/storage/7N-ZDGtCZq01gFJQEd8eqPuiGbumCWtPoje-4KMVfzIFs1)
> rsync: connection unexpectedly closed (2545228 bytes received so
> f
ZP1DdbboxuS3xGZphQe1,*,2)
[sender] make_file(storage/JKsb9I8-7dP6cFjao0omRCfj,*,2)
[sender]
make_file(storage/O4tK1PXwyelx8Oju,1sC-xfRUYg5cnMrPxeo5FTpE-AEM-,*,2)
send_files starting
send_files(3,
/srv/encfs-mirrors/storage/7N-ZDGtCZq01gFJQEd8eqPuiGbumCWtPoje-4KMVfzIFs1)
rsync: connection
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
cache/apt/archives/sendmail-bin_8.13.1-20_i386.deb,2066)
set modtime of public/backups/cms1.it-factory.local/etc/.profile.RboUbQ to
(1100790549) Thu Nov 18 16:09:09 2004
rsync: connection unexpectedly closed (28352 bytes received so far) [sender]
_exit_cleanup(code=12, file=io.c, line=420): en
Hello,
i use rsync from Windows to rsync on Linux via ssh and get IO Errors
and connection unexpectedly closed errors on almost every sync run.
Can anybody give me some hints on how to track down the problem?
thx, Chris
2008/10/11 09:41:04 [13744] rsync to backup// from UNKNOWN (w.x.y.z)
2008
On Tue, 2008-07-08 at 14:29 -0300, Marcelo Leal wrote:
> Thanks a lot!
> ps.: Why google did not find [the issues and debugging page]? :-)
The samba.anu.edu.au version of the page is the first result when I
search for "rsync connection unexpectedly closed".
Matt
signature.asc
D
Thanks a lot!
ps.: Why google did not find it? :-)
2008/7/8 Matt McCutchen <[EMAIL PROTECTED]>:
> On Tue, 2008-07-08 at 09:08 -0300, Marcelo Leal wrote:
>> Every night i receive the messages:
>>
>> rsync: connection unexpectedly closed (14801530 bytes received so f
On Tue, 2008-07-08 at 09:08 -0300, Marcelo Leal wrote:
> Every night i receive the messages:
>
> rsync: connection unexpectedly closed (14801530 bytes received so far)
> [generator]
> rsync error: error in rsync protocol data stream (code 12) at
> io.c(453) [generator=2.
Hello all,
Every night i receive the messages:
rsync: connection unexpectedly closed (14801530 bytes received so far)
[generator]
rsync error: error in rsync protocol data stream (code 12) at
io.c(453) [generator=2.6.9]
but the synchronization process seems to be right... so the question:
What
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
Matthias,
We had the same problem with the rsync timing out. We Rsync'ed to a
second harddisk ( hdc1) and the timeout occurred. When rsyncing to the
first harddisk, containing the whole OS ( Redhat 7.2), it worked without
a problem.
We tried Mandriva 2007 with the same setup and result. But the e
On Thu, Mar 08, 2007 at 10:32:04AM -0700, Phil Hassey wrote:
> someone suggested that I add this to my ~/.ssh/config file:
>
> ServerAliveInterval 5
> ServerAliveCountMax 120
Those options only apply to protocol 2 connections (which people should
be using anyway these days). There are also setti
Thanks for rsync - it's great! I use it for all my backups.
I use rsync via SSH. Recently - I was having trouble with my backups:
rsync: connection unexpectedly closed (4968349 bytes received so far)
[receiver]
rsync error: error in rsync protocol data stream (code 12) at
io.c(453) [rec
a network timeout.
io timeout after 60 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(171)
[receiver=2.6.8]
_exit_cleanup(code=30, file=io.c, line=171): about to call exit(30)
rsync: connection unexpectedly closed (1179625 bytes received so far)
[generator]
rsync er
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|
|unexpectedly closed (3207118|unexpectedly closed (3207118
|bytes received so far) |bytes received so far)
|[generator] |[generator]
--- Comment #1 from [EMAIL PROTECTED] 2006-04-02 00:18 MST ---
The first item in the FAQ covers
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
Hi, All!
I've got some errors while trying to sync 2 directory trees.
[EMAIL PROTECTED] ~] rsync -azv way:/www/sin/ /www/sin/
receiving file list ... done
./
[snip]
docs/members/popol/pop0207.con
rsync: connection unexpectedly closed (275727980 bytes received so far)
[receiver]
rsync
>
> 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
-
pansion in such
cases, and -a implies -t already; i.e. use:
/usr/bin/rsync -a rsync.server.domain::dir/ /destination
from the command prompt without any problem but if I use the same rsync
command from cron I get the following error
daemon.warn: May 30 15:18:42 rsyncd[24703]: rsync: connection
un
.server.domain::dir/ /destination
> from the command prompt without any problem but if I use the same rsync
> command from cron I get the following error
>
> daemon.warn: May 30 15:18:42 rsyncd[24703]: rsync: connection unexpectedly
> closed (0 bytes received so far) [receiver]
&
unexpectedly
closed (0 bytes received so far) [receiver]
daemon.warn: May 30 15:18:42 rsyncd[24703]: rsync error: error in rsync
protocol data stream (code 12) at io.c(420)
Could somebody tell me why.
With kind regards,
Maurice Lucas
TAOS-IT
--
To unsubscribe or change options: https
you omit it?
> Or are you doing a file listing?
I left out the destination directory when typing the
above. It's more like just a "." .
> > rsync: connection unexpectedly closed (9382362
> bytes received so far) [receiver]
> > rsync: connection unexpectedly closed
On Sat, Mar 05, 2005 at 06:53:08AM -0800, Lawrence Wong wrote:
> # rsync -av --stats --delete --force
> ftp.funet.fi::CPAN
Hmm, there's no destination directory specified there. Did you omit it?
Or are you doing a file listing?
> rsync: connection unexpectedly closed (9382362 byt
--force
ftp.funet.fi::CPAN
rsync: connection unexpectedly closed (9382362 bytes
received so far) [receiver]
rsync error: error in rsync protocol data stream (code
12) at io.c(391)
rsync: connection unexpectedly closed (9382362 bytes
received so far) [generator]
rsync error: error in rsync protocol data
On Wed, Jan 26, 2005 at 12:34:02PM -0600, David L. Harfst wrote:
> building file list ... done
> rsync: connection unexpectedly closed (69 bytes read so far)
It would probably help to upgrade the server to 2.6.3, since 2.6.2 did
not pass back most errors to the client. Also, a 2.6.3
g file list ... done
rsync: connection unexpectedly closed (69 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(342)
I don't think it is a failed authorization because it would tell me that
in the log file on the server. It seems to be getting the connecti
list = false
auth users = sync
From the client, also Fedora Core 2, also running 2.6.2-1 I'm doing the
following:
rsync -avH --delete-excluded --delete \
--password-file=/etc/rsyncval.pwd \
FOCUS [EMAIL PROTECTED]::validation
The output is as follows:
building file list
Utter silence!
socnt01:~ # ssh [EMAIL PROTECTED] 'missing-rsync 2>&1'
socnt01:~ # ssh [EMAIL PROTECTED] 'echo testing >&2'
socnt01:~ #
The key in authorized_keys is completely vanilla, as generated by
ssh-keygen. Here's the last few characters:
HDX9YgmYKiYyOvQMDKpeJXs= [EMAIL PROTECTED]
On Thu, Jan 13, 2005 at 08:17:42PM +, Nigel Gilbert wrote:
> Interestingly, when I use ssh to execute a non-existent command on the
> remote machine, no error message is returned
Fascinating. Perhaps your ssh isn't returning the stderr output? Try
these commands:
ssh [EMAIL PROTECTED] '
Interestingly, when I use ssh to execute a non-existent command on the
remote machine, no error message is returned (BTW, it is not clear in
your email below whether you mean by "Your shell" the shell on the
local machine - which certainly will complain if asked to execute a
non-existent comman
On Thu, Jan 13, 2005 at 05:20:51PM +, Nigel Gilbert wrote:
> This might be thought to be a bug or a missing feature in rsync; rsync
> could have produced a more comprehensible error message.
Your shell should have told you about the command problem -- for
instance, I see this trying to run th
nt:
rsync -v -a --delete --numeric-ids -e "ssh -i /root/.ssh/id_rsa" \
/bin/ [EMAIL PROTECTED]:/export/home/scbackup/socnt01/bin/
I immediately get:
rsync: connection unexpectedly closed (0 bytes received so far)
[sender]
rsync error: error in rsync protocol data stream (code 12) at
i
hy is this 'boot' and not 'bin' according to your rsync command?
In any case, it's odd that this rsync command is being echoed back.
> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
> rsync error: error in rsync protocol data stream (code 12)
When I run
rsync -v --exclude-from= -a --delete --numeric-ids -e ssh -i
/root/.ssh/id_rsa /bin/ [EMAIL PROTECTED]:/export/home/scbackup/socnt01//bin/
I immediately get:
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code
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
1 - 100 of 113 matches
Mail list logo
