rsync error - error in rsync protocol data stream (code 12) at io.c(420)
Hi, When i try to run rsync command from command linne it is working fine.Below is the command /usr/bin/rsync --compress \ --verbose \ --rsh=ssh \ --times \ --owner \ --group \ --ignore-times \ --links \ --perms \ --recursive \ --size-only \ --delete \ --force \ --numeric-ids \ --stats \ /etc \ [EMAIL PROTECTED]:/home/backup/thismachine/ when i try to use shell script for this #! /bin/bash /usr/bin/rsync --compress \ --verbose \ --rsh=ssh \ --times \ --owner \ --group \ --ignore-times \ --links \ --perms \ --recursive \ --size-only \ --delete \ --force \ --numeric-ids \ --stats \ /etc \ [EMAIL PROTECTED]:/home/backup/thismachine/ I am getting the following error ssh: connect to hostx.x.x.x port 22: No route to hostrsync: connection unexpectedly closed (0 bytes received so far) [sender]rsync error: error in rsync protocol data stream (code 12) at io.c(420) this is related to ssh i believe.But when i try to use from the command prompt it is working without any problem through ssh Please some one help me how to fix this error in shell script.Because i want to schedule this from cron Thanks for your time -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync error - error in rsync protocol data stream (code 12) at io.c(420)
thanks for your reply.I have tried that also but still getting the same error On 09/12/05, Paul Slootman [EMAIL PROTECTED] wrote: On Fri 09 Dec 2005, gg gg234 wrote: ssh: connect to host x.x.x.x port 22: No route to host rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(420) this is related to ssh i believe.But when i try to use from the command prompt it is working without any problem through sshPerhaps you have some host-specific options in ~/.ssh/config that aren'tpicked up when running from cron?Or there's some hidden character after one of the backslashes, or something like that... Try putting it all on one line in the script.Paul Slootman -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Any change of rsync using threads instead of fork?
Nelson H. F. Beebe wrote: List traffic today asks about changing rsync to use lightweight threads instead of heavyweight fork. Before rushing into building a threads version of rsync, please READ this recent article You didn't post a link directly to the article, just to the gateway page. The ACM requires a fee to read the article (or a pre-paid account). I considered paying the fee, if it's not much, but it requires user registration before it will even say what the fee is; I don't purchase from sites which won't state the price up front. From the abstract: We provide specific arguments that a pure library approach, in which the compiler is designed independently of threading issues, cannot guarantee correctness of the resulting code. That's correct. Any implementor of a sound thread library, and of compilers used with such libraries, knows that there are memory aliasing optimisations which defeat essential synchronisation barriers in functions like `pthread_mutex_lock'. That is a cause of unsafe code. This is not new knowledge, but perhaps needed a paper all the same. _Real_ systems which implement the POSIX threads specification (pthreads) are not implemented in that way. They all require, in some way, something special of their compiler. Even if that's just a guarantee that calling (at least some marked) external functions may read and write all program data which can be reached from multiple execution paths. Programs which call longjmp() and setcontext() have similar issues. Therefore unix compilers, and their optimisations, have to take into account those sorts of things. If a system claims it supports POSIX threads (and if it really does), then you can rely on this. That doesn't mean there aren't implementations with bugs, but the ones which really do conform (and generally vendors do put the effort in), are quite safe to use. A few auxiliary points: 1. The request is not to use lightweight threads for no reason, or some vagueness of efficiency. It is because some C environments _cannot do_ fork. The only way to implement rsync on those is either using threads or state machines. 2. A thread-safe version of rsync does not mean that you have to use threads on all platforms, only that it's an option. Indeed, if rsync is to remain portable, it must continue to be compilable without threads too. Maybe it should default to using fork, except when fork is not available, and when testing. 4. I have been involved in the design of pthreads libraries on GNU/Linux. I can assure you the various synchronisation primitives do what they say they do, at least on a distro where the appropriate C compiler is used with the appropriate library, and that it is possible to build correct, safe code on real platforms using those primitives. (its author is also the co-author of the well-known, and widely used, gc (garbage collecting version of C malloc and C++ new) library Yes, it is widely used. Did you know Boehm's gc library is compiler-unsafe to a far greater degree than most thread libraries? Still, it is widely used anyway :) -- Jamie -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Any change of rsync using threads instead of fork?
Wayne Davison wrote: On Thu, Nov 24, 2005 at 03:22:23AM +, Jamie Lokier wrote: Is there any likelihood of changing the rsync code to use threads instead of processes? I just thought about this a bit more, and it didn't seem as large a task as I had originally assumed it would be. I also remembered that I'm going to need something like this (*) to effect my desired changes of decreasing memory use and improving speed, so I've coded up a first-cut version: http://opencoder.net/threaded-receiver.diff This applies to the very latest CVS source (which is also available in a just-updated nightly tar file). The code does not attempt to discern what kind of threading is available, so that will probably need to be improved for systems that don't use pthreads.h. If anyone tries this out, please let me know how it goes and any problems you run into. Thank you! I don't know if I'll try it now, as I'm working on an alternate solution to our project which I need to be confident will work, but if I do I'll let you know how it went. -- Jamie -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: batch applied: Directory not empty (66)
On Wed, Dec 07, 2005 at 10:45:35PM -0800, Raymond Keller wrote: In my source I have a directory that changed to a file. I know this requires --force or --delete, but using --only-write-batch I get no error until I attempt to apply the batch. That's correct -- there's no problem generating the batch when the destination is not being modified (rsync notices that the file changed into a dir, but doesn't need to check if it is empty or not since it's not actually being removed). When the batch is read back, the user has the option of using the --force option or not, regardless of how the batch was made (since it doesn't affect the making of a batch). In fact, there is no problem if the user first uses the batch file without --force, notices that it is needed, and then re-runs the same batch file with --force since rsync skips all the already-applied changes prior to the change that caused the halt. Also, unrelatedly, when rsync refuses to apply a specific change from a batch due to the destination not being in the right state, is there any way to get more detail on what aspect triggered the refusal? I assume you mean the Skipping batched update message, that only occurs for one reason: the file is up-to-date (for whatever definition of up-to-date was in effect when the batch was created). The only other refusal happens when the changes get applied and the file fails the checksum (causing rsync to discard the bogus file unless --partial was in effect). ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: batch applied: Directory not empty (66)
* Wayne Davison ([EMAIL PROTECTED]) [20051209 12:10]: On Wed, Dec 07, 2005 at 10:45:35PM -0800, Raymond Keller wrote: In my source I have a directory that changed to a file. I know this requires --force or --delete, but using --only-write-batch I get no error until I attempt to apply the batch. That's correct -- there's no problem generating the batch when the destination is not being modified (rsync notices that the file changed into a dir, but doesn't need to check if it is empty or not since it's not actually being removed). When the batch is read back, the user has the option of using the --force option or not, regardless of how the batch was made (since it doesn't affect the making of a batch). In fact, there is no problem if the user first uses the batch file without --force, notices that it is needed, and then re-runs the same batch file with --force since rsync skips all the already-applied changes prior to the change that caused the halt. I get it; distinct create and apply phases, with their particular behaviors/needs. Also, unrelatedly, when rsync refuses to apply a specific change from a batch due to the destination not being in the right state, is there any way to get more detail on what aspect triggered the refusal? I assume you mean the Skipping batched update message, that only occurs for one reason: the file is up-to-date (for whatever definition of up-to-date was in effect when the batch was created). The only other refusal happens when the changes get applied and the file fails the checksum (causing rsync to discard the bogus file unless --partial was in effect). I do mean that, yes. I had the misunderstanding that the destination file had to be in a state identical to the corresponding destination file against which the batch was originally created, or an update would not be applied. Thanks for clarifying. I see now how I came into this erroneous idea. The man page says: ``The read-batch option expects the destination tree that it is updating to be identical to the destination tree that was used to create the batch update fileset.'' I failed to closely read the following sentences which explain exactly what you've told me here. Thanks for tolerating (and graciously answering) a man page question. And thanks for (maintaining) the software! Like gajillions of others these days, I have my backups based on rsync. 52 snapshots of three different systems, spanning two years, taking 31 gigs, with new snapshots added six times daily. I couldn't feel any more secure if I wore pants with both suspenders _and_ a belt. RSK -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
rsync 2.6.6 nasty bug?
I believe I have encountered a nasty bug with rsync 2.6.6 --delete-excluded option. When this is enabled, rsync's operation appears to break entirely. I have a script that I've been using for a few years. The script hasn't changed in the last year or so. Recently I upgraded from SuSE 9.3 to SUSE 10.0 which means that I went from rsync 2.6.3 (+ patches, I assume) to rsync 2.6.6. It was at this point that the script stopped working. I haven't had time to diagnose it until today. These are my findings: To make sure it wasn't some non-rsync aspect of the system, I forcibly downgraded the rsync installation to the one from SuSE 9.3. The script worked great! I then installed the one from SUSE 10.0 - the script was broke. I eventually boiled everything down to this: The invocation on the client machine is: rsync -av --delete-excluded --exclude-from=excludes \ -e 'ssh' remote_machine: This is what I get: [client] parse_filter_file(excludes,0,3) [client] add_rule(- *.mp3) ... (Client) Protocol versions: remote=29, negotiated=29 (Server) Protocol versions: remote=29, negotiated=29 building file list ... [sender] make_file() - lots of this ... recv_file_list done rsync: writefd_unbuffered failed to write 4092 bytes: phase send_file_entry [sender]: Broken pipe (32) get_local_name count=0 notebook.tmp generator starting pid=8361 count=0 delta-transmission enabled generate_files phase=1 recv_files(0) starting Invalid file index: 1701734919 (count=0) [receiver] _exit_cleanup(code=2, file=sender.c, line=163): entered rsync error: protocol incompatibility (code 2) at sender.c(163) _exit_cleanup(code=2, file=sender.c, line=163): about to call exit(2) rsync: connection unexpectedly closed (9 bytes received so far) [generator] _exit_cleanup(code=12, file=io.c, line=434): entered rsync error: error in rsync protocol data stream (code 12) at io.c(434) _exit_cleanup(code=12, file=io.c, line=434): about to call exit(12) rsync: connection unexpectedly closed (8 bytes received so far) [sender] _exit_cleanup(code=12, file=io.c, line=434): entered rsync error: error in rsync protocol data stream (code 12) at io.c(434) _exit_cleanup(code=12, file=io.c, line=434): about to call exit(12) If I remove the --delete-excluded part from the *client* invocation, everything appears to work just fine (except the excluded files aren't deleted). It doesn't always die in the same place (same filename), but it always dies, and does so fairly quickly. I can supply portions of straces, etc... if anybody is interested. This seems like a pretty serious bug. -- Jon Nelson [EMAIL PROTECTED] -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
