Re: error in rsync protocol data stream
Is your USB disk a usb-1 device? I got various errors due to the slow access times over usb-1 (not rsync's problem). I was able to reduce the number of errors using the --bwlimit option to slow down rsync so the device could keep up better. I've had no problems since I upgraded to usb-2. -Lee Date: Thu, 12 Feb 2004 14:14:12 -0500 From: Ray Lischner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: error in rsync protocol data stream X-Original-To: [EMAIL PROTECTED] X-Injected-Via-Gmane: http://gmane.org/ X-Complaints-To: [EMAIL PROTECTED] X-Gmane-NNTP-Posting-Host: dsl092-046-090.blt1.dsl.speakeasy.net User-Agent: KNode/0.7.2 X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.1.3 On Thursday 12 February 2004 12:44 pm, Ray Lischner wrote: I am trying to backup an entire disk to a USB-mounted disk, for backup purposes. Many files are copied, but eventually rsync dies: I tried it again, and this time it fails at a different point and with a different error: $ rsync -axHSv --delete /backup /media/sda1 ... rsync: writefd_unbuffered failed to write 32768 bytes: phase unknown: No buffer space available rsync error: error in rsync protocol data stream (code 12) at io.c(666) As I mentioned in my previous post, the system has 192MB RAM, 400MB swap. The file system I am trying to copy takes up about 15GB. -- Ray Lischner, author of C++ in a Nutshell http://www.tempest-sw.com/cpp -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Lee Eakin - [EMAIL PROTECTED] Gerrold's Fundamental Truth: It's a good thing money can't buy happiness. We couldn't stand the commercials. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: specifying a list of files to transfer
---begin quoted text--- From: jw schultz [EMAIL PROTECTED] Date: Fri, 17 Jan 2003 16:21:59 -0800 On Fri, Jan 17, 2003 at 04:42:51PM -0600, Dave Dykstra wrote: On Thu, Jan 16, 2003 at 11:14:50PM -0800, Wayne Davison wrote: Oh, right, I hadn't thought of that implication of the way this is implemented. Definitely we want the -R functionality implied. That's the only way I can imagine people wanting to use this. I can think of a couple of uses for a --no-relative option. It would not be the common case, I agree with the examples below. They illustrate both the common case and the exception quite well. I can see a case where you want to backup several critical files from a one system to a single (flat) directory on another. The flattened example below would work well for this. Of course the example also shows a filename stepping on another, but since --no-relative would would be the exception instead of default, the user can deal with it (they explicitly asked for it after all). I can also see a case where you have several files in a single directory that you want to update from a master repository, but the repository has them spread out in different dirs (may due to different files for different architectures). This option could allow you to update say /usr/local/bin pulling from several known locations save in the distlist file. Sorry, just had to throw this in. I understand stand the desire to avoid feeping creaturism. Making software more useful to more people with hideous bloat is a very difficult balance. -Lee rsync -lptgoDu --delete --files-from=distlist distserver::8.0/i386 /root2 where distlist is etc/init.d/rsyncd etc/rsyncd.conf usr/bin/rsync usr/bin/rsyncstats usr/sbin/rcrsyncd usr/sbin/rsyncd usr/share/doc/packages/rsync usr/share/doc/packages/rsync/COPYING usr/share/doc/packages/rsync/README usr/share/doc/packages/rsync/tech_report.ps usr/share/doc/packages/rsync/tech_report.tex usr/share/man/man1/rsync.1.gz usr/share/man/man5/rsyncd.conf.5.gz It should not do /root2/i386/etc/init.d/rsyncd and so on as -R would have it. It should not create (flattened) /root2/rsyncd # from /etc/init.d /root2/rsyncd.conf /root2/rsync /root2/rsyncstats /root2/rcrsyncd /root2/rsyncd # from usr/sbin? /root2/COPYING /root2/README /root2/tech_report.ps /root2/tech_report.tex /root2/rsync.1.gz /root2/rsyncd.conf.5.gz What it should create or update is /root2/etc/init.d/rsyncd and so on. and it should be equivalent to rsync -lptgoDu --delete --files-from=distlist \ distserver:/data/distribution/8.0/i386 /root2 or rsync -lptgoDu --delete --files-from=distlist \ /data/distribution/8.0/i386 client:/root2 If /root2/usr/share/doc/packages doesn't exist it should be created with perms from source but it should not be recoursed. This example is drawn from one of the most recent emails requesting this feature. ---end quoted text--- -- Lee Eakin - [EMAIL PROTECTED] Life's not fair, but the root password helps. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: specifying a list of files to transfer
---begin quoted text--- From: Wayne Davison [EMAIL PROTECTED] Subject: Re: specifying a list of files to transfer Date: Wed, 15 Jan 2003 10:10:29 -0800 On Tue, Jan 14, 2003 at 10:01:47PM -0600, Lee Eakin wrote: Yes, people do restrict args via ssh key restrictions. OK, I thank you both for enlightening me on the subject. My current patch applies the sanitize_path() function to all names read via the --files-from option, regardless of whether we're pushing or pulling. This means that all leading slashes are dropped from file names as well as all leading ../ prefixes, and that any infix dir/../ combos are removed. This ensures that we can't get above the root dir that was specified on the command-line. That's awsome. Now as long as I want to allow access to the given portion of the file tree I can allow files-from. Now if I can only figure out a way to intercept the list when I need to be real picky about which individual files are accessed ... so any sanitize code could first make sure all pathnames begin with a valid module and then make sure the file or dir is really inside that module. This isn't needed since the module name is specified on the command-line and then all paths are relative to the directory that was specified in that module. For instance: rsync --files-from=foo remote::module/bar forces all pathnames read to be relative to the bar dir of the module. If no /bar path was specified, the paths would all be relative to the root-dir of the module. That's cool too, so no additional/special code to handle server-mode ;) I like this a lot, now to test ... ---end quoted text--- -Lee -- Lee Eakin - [EMAIL PROTECTED] Benchley's Law of Distinction: There are two kinds of people in the world, those who believe there are two kinds of people in the world and those who don't. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: specifying a list of files to transfer
I like it (except for the work). I don't think I'm ready to code up a filter yet, but it is good to know the general theory in case I need to use it. Of course, if I keep thinking about it I'll probably run across a situation where it's use would greatly speed/simplify my life, so maybe I should go ahead and throw something together ;). Yes, the filter would need to sit in the middle for the duration of the xfer, but I am thinking of those situations where the tree scan is very costly so the little overhead and complexity of the filter would be worth it. -Lee ---begin quoted text--- From: Wayne Davison [EMAIL PROTECTED] Date: Wed, 15 Jan 2003 13:34:08 -0800 On Wed, Jan 15, 2003 at 02:48:05PM -0600, Lee Eakin wrote: Now if I can only figure out a way to intercept the list when I need to be real picky about which individual files are accessed ... This should be possible with a filter process. Here's how the new, slightly tweaked protocol works: 1. The normal startup exchange occurs up to the point just before where the (normal) file info (names + attributes) starts to flow from the sender to the receiver. 2a At this point IFF the sender is the remote process (i.e. we're pulling files), the receiver begins to send file names (separated by either newlines or nulls, as indicated by the --null option) over the socket (normally there is no data being sent to the sender during this stage). The end of the list is marked by an empty entry. (Note that the receiver begins receiving file info from the sender during this stage, so it must do both things at once without blocking.) If the recursive flag is set, the receiver may get more names back than it sends out. 2b Alternately, if the sender is the local process, the normal file info transfer happens (without anything new occurring over the socket). 3. The rest of the transfer proceeds as normal. So, if a filter understood the protocol enough to be able to pass through all the initial rsync data, it could actually look at all the names that go over the wire and allow/disallow/tweak them however it desired. (It's sad that this filter would then have to continue to relay all the data over the socket after its work was done, but that's the price you pay.) You'd just have to look for the --null option on the command-line to know if you're looking for a newline or a null EOL character, and stop scanning at the first empty name. Alternately, you could just disallow the --files-from option and not worry about authorizing the data. ---end quoted text--- -- Lee Eakin - [EMAIL PROTECTED] Lynch's Law: When the going gets tough, everybody leaves. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: specifying a list of files to transfer
FYI, pulling multiple files from a daemon currently supported (well, it works). Given a package of foo you can specify: rsync -av 'remote::foo/file1 foo/file5' /tmp It appears the daemon does proper splitting based on either white-space, or possibly the current value of $IFS in the daemon's environment? One other note, I did not determine whether it was a Solaris issue, or string length limit, or file argument limit, but in my tests I could only specify about 20 files using this method. When I went over the limit no files were xfered. I was testing this a while back (just to see if I could), so I don't remember the exact limit, but I am fairly sure I experimented with shorter pathnames and it did not effect the max filenames I could specify. Oh, yes. I did not have the same limitation over ssh. The remote shell seems to pass any number of filenames to the remote end (of course there may be limits depending on what login shell is used on the remote server). -Lee ---begin quoted text--- From: Wayne Davison [EMAIL PROTECTED] To: jw schultz [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: specifying a list of files to transfer User-Agent: Mutt/1.3.28i X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.13 X-Original-Date: Tue, 14 Jan 2003 18:41:22 -0800 Date: Tue, 14 Jan 2003 18:41:22 -0800 On Tue, Jan 14, 2003 at 04:35:40PM -0800, jw schultz wrote: Absolute paths are bad news here. Especially when dealing with an rsync daemon. Yes, this is something that needs to be dealt with for daemon mode since it does not appear to have been possible to specify multiple filenames to pull before (unlike remote-shell mode). For non-daemon mode, the code is the same as it always was in this regard. For example, this command: rsync -av /tmp/one /foo/two /bar/three dest: is no different than this command: rsync -av --files-from=list /tmp dest: where list contains: one /foo/two /bar/three In the patch I posted earlier, daemon mode did not work with the new --from-files option. My latest patch has this fixed: http://www.clari.net/~wayne/rsync-files-from.patch And it also runs the filenames through sanitize_path() in daemon mode (when chroot is not specified, at least -- I haven't tested a chroot version yet). ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html ---end quoted text--- -- Lee Eakin - [EMAIL PROTECTED] With sufficient thrust, pigs fly just fine. -- RFC 1925 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: specifying a list of files to transfer
Please pardon my butting in again. I am not a developer, but I am very interested in this option because I've need it in the past and had to work around the lack of it with include/exclude options (I wanted to sync only a few files from a large directory, and needed it to work via the daemon for anonymous access). I also maintain the perl wrapper File::Rsync so I do my best to understand all of the options so I can handle them properly in the perl module. ---begin quoted text--- From: Wayne Davison [EMAIL PROTECTED] Date: Tue, 14 Jan 2003 19:39:49 -0800 On Tue, Jan 14, 2003 at 07:02:58PM -0800, jw schultz wrote: Up till now rsync hasn't touched anything outside of the paths specified on the command-line. Changing that would mean access to rsync via ssh would no longer be restricted, just disabled. Are you saying that some people have special ssh scripts that check and/or tweak the file names on the command-line to ensure they fall with certain bounds when running rsync commands? I.e., if someone ran this command: rsync -av -e ssh source:dir /foo/two /bar/three /tmp the remote ssh setup would handle the presence of the extra /foo/two, /bar/three args? If so, I hadn't realized that people were limiting ssh access by more than the traditional user/group/permissions access. Yes, people do restrict args via ssh key restrictions. I have done this myself on many occasions. The environment variable SSH_ORIGINAL_COMMAND is passed to the actual command called from the command= key option so I write a small script to parse thru the variable checking each arg making sure they are what I expect (and possibly modifying them). I also check pathnames to make sure they all fit my restrictions. I then either exec rsync, or email the offending command to root if I find an exception (the mail also makes debugging easier). I assume the remote end will get the expanded contents of files-from so ssh command parsing would still work properly. Sanitizing the paths to force them to be relative on pulls but not pushes would be too asymetrical for my liking. I agree that if we find that we want to sanitize the paths in some cases that we should just make it the default for files-from -- i.e. make it where nothing can get beyond the root dir specified on the command-line. I'd rather just disallow or sanitize absolute paths. If you try to pull a full pathname from a daemon 'rsync remote::/foo' it errors out with: ERROR: The remote path must start with a module name not a / so any sanitize code could first make sure all pathnames begin with a valid module and then make sure the file or dir is really inside that module. ---end quoted text--- -- Lee Eakin - [EMAIL PROTECTED] - Internet/Naming Services, Texas Instruments LAWS OF COMPUTER PROGRAMMING: II. Any given program costs more and takes longer. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: specifying a list of files to transfer
---begin quoted text--- From: jw schultz [EMAIL PROTECTED] Date: Tue, 14 Jan 2003 20:07:58 -0800 Nope. The files-from contents needs to passed on stdin otherwise we would hit command-line length limits. That is why i'm stressing the fact that allowing paths not within the source or destination trees specified on the command-line would bypass your ssh command= wrapper restrictions. Oh, I see now. Yes that could be a serious hole. If the remote command included an option (maybe a dummy --files-from) then the ssh wrapper could at least abort and notify when it sees it. -Lee -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: specifying a list of files to transfer
From: jw schultz [EMAIL PROTECTED] Date: Tue, 14 Jan 2003 20:33:46 -0800 On Tue, Jan 14, 2003 at 10:15:42PM -0600, Lee Eakin wrote: ---begin quoted text--- From: jw schultz [EMAIL PROTECTED] Date: Tue, 14 Jan 2003 20:07:58 -0800 Nope. The files-from contents needs to passed on stdin otherwise we would hit command-line length limits. That is why i'm stressing the fact that allowing paths not within the source or destination trees specified on the command-line would bypass your ssh command= wrapper restrictions. Oh, I see now. Yes that could be a serious hole. If the remote command included an option (maybe a dummy --files-from) then the ssh wrapper could at least abort and notify when it sees it. If you look at Wayne's description of the patch the remote command does have a --files-from=- on it's command-line. However it would be a shame to disable that performance enhancing facility if we just need sanitize the contents of the file-from list and require that it only specify paths relative to the source and dest trees. I suppose we could allow an option that would permit unsanitized paths. I would agree. If the paths are known to be relative (forced to be by the rsync running where the ssh restriction is) then (assuming the wrapper's intent is to allow access to the whole sub-tree) it could allow the files-from option. If you only want to allow access to specific files, then it would still have to disallow the option. I can think of one possible way for the wrapper to find out what files are being requested, but don't know enough about the interconnect between the 2 rsyncs to know if it would break it (probably). If the wrapper could run a modified version of the original command without a destination it would print out a list of the files (remember that if you do not give a destination it prints something similar to 'ls -l' with includes and excludes applied) then it could walk the output and verify all the paths. If it passed inspection, it could call the real command passing the file list to stdin itself. It would have to attach stdout and stderr properly, and may even have to act as a pass-thru for further data coming on stdin. It would be complicated, but might be possible if the dummy (no destination run) did not close off the connection after reading the file list, and/or the handshaking was clearly documented so non-developers could understand it. I only throw this idea out because I would really like files-from to work even in a restricted-access mode. It is a BIG win over parsing a large dir for includes/excludes. -- Lee Eakin - [EMAIL PROTECTED] Murphy's Military Laws: 6. The buddy system is essential to your survival; it gives the enemy somebody else to shoot at. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Rsync, Perl and samba filesystem (smbfs)
Dave, Yes the problem was in the perl code. Chris was using my File::Rsync perl module. He and 2 others reported a case where the module would hang, but calling same rsync command from a shell would work properly. I could not reproduce the symptom, but added some additional EOF checks on the pipe and a trap for SIGCHLD. Chris and one other person have both reported that it fixed the hangs. I'm still waiting for report from the third person. I'll be posting the updated version (0.23) to CPAN soon (after a little more testing to make sure I didn't break anything). In the mean time, if anyone else is having similar problems and would also like to test it out, you can find it here: http://www.japh.net/File-Rsync-0.23.tar.gz Any issues (good or bad) are welcome. -Lee ---begin quoted text--- Delivered-To: [EMAIL PROTECTED] From: Dave Dykstra [EMAIL PROTECTED] To: Dr. Poo [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Rsync, Perl and samba filesystem (smbfs) Mail-Followup-To: Dave Dykstra [EMAIL PROTECTED], Dr. Poo [EMAIL PROTECTED], [EMAIL PROTECTED] User-Agent: Mutt/1.3.27i X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.13 X-Original-Date: Thu, 5 Dec 2002 14:36:10 -0600 Date: Thu, 5 Dec 2002 14:36:10 -0600 Also, you'll probably want to use the --whole-file option of rsync to minimize the amount of samba network traffic (although J.W. is probably right about the main problem being in perl). That's the default in later versions of rsync when copying between two local file paths. - Dave Dykstra On Tue, Dec 03, 2002 at 03:49:41PM -0800, jw schultz wrote: On Tue, Dec 03, 2002 at 04:33:38PM -0600, Dr. Poo wrote: My name is Chris, Hi! I've got rsync being called from a perl script that is called by cron (or for that matter, by hand) and when I 'rsync' a locally mounted samba filesystem (eg. to /mnt/smbfs), it successfully syncs the smbfs to the destination directory, but without reason hangs... and take all my cpu power... When i look at all the processes running, the rsync pid is defuct... and it's actually saying that the parent perl script that made the call is gobbling up all my cpu resources This ONLY happens (so far anyways) with the samba mounts... Any suggestions?? Thanks a bundle! -Chris The fact that the rsync process is defunct tells me that it isn't rsync. Defunct (also known as the zombie state) means that the process has exited but the parent (your perl script) has not reaped the status with wait(). It sounds like your perl script is reading from the rsync output and failing to check for EOF. If you described or better sent your perl script someone might be able to help. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html ---end quoted text--- -- Lee Eakin - [EMAIL PROTECTED] Harrison's Postulate: For every action, there is an equal and opposite criticism. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.4 -v output (minor knit)
Dave,
Awesome! Nice clean output now with single -v. I guess I need to make
sure the perl File::Rsync module is up-todate with 2.5.4 ;)
Thanks again to all the developers, Now that rsync exists I can't live
without it. I use it all day long for all kinds of transfers, not to
mention it is an integral part of our corporate DNS process and our DRP
solution for off-site backup of critical servers.
-Lee
---begin quoted text---
From: Dave Dykstra [EMAIL PROTECTED]
Subject: Re: rsync 2.5.4 -v output (minor knit)
Date: Thu, 14 Mar 2002 15:27:49 -0600
Ah, yes. Here's a fix. I submitted it to rsync CVS.
- Dave
--- flist.c.O Thu Mar 14 15:26:24 2002
+++ flist.c Thu Mar 14 15:18:52 2002
@@ -988,8 +988,9 @@
send_file_entry(NULL, f, 0);
}
- if (show_filelist_p())
+ if (show_filelist_p() f != -1) {
finish_filelist_progress(flist);
+ }
clean_flist(flist, 0);
---end quoted text---
--
Lee Eakin - [EMAIL PROTECTED]
SPOON! --The Tick There is no spoon. --Neo, The Matrix
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.4 -v output (minor knit)
Dave, I tried a simple case but could not reproduce it, but it is reliable from my script. I'll work out a test case today by ripping apart my script and send along. -Lee ---begin quoted text--- Delivered-To: [EMAIL PROTECTED] From: Dave Dykstra [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: rsync 2.5.4 -v output (minor knit) Mail-Followup-To: Dave Dykstra [EMAIL PROTECTED], [EMAIL PROTECTED] User-Agent: Mutt/1.3.27i X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.8 Date: Thu, 14 Mar 2002 12:37:54 -0600 On Wed, Mar 13, 2002 at 03:44:36PM -0600, Lee Eakin wrote: I noticed a difference in verbose output that appears to be unintentional. it first prints 'receiving file list ...', then builds the list and prints 'done\n'. I haven't figured out the exact conditions yet, but with multiple remote sources (remote shell expands) it sometimes prints the 'done\n' message multiple times. I have a script I use to sync up my dot-files with multiple files and excludes that prints the 'done\n' line 16 times. Is there a simple fix? People parsing the output of -v may want to be aware of this. I first saw it in 2.5.3. -Lee I have not seen this, and I would appreciate a simple set of steps to reproduce it. I touched that code recently so I guess I should fix it. I tried rsync -av 'host:`echo dir1/*`' dir2 and that didn't do it. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html ---end quoted text--- -- Lee Eakin - [EMAIL PROTECTED] - Internet/Naming Services, Texas Instruments HELO. My $name is sendmail.cf. You filled my spooldir. Prepare to VRFY. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.4 -v output (minor knit)
Dave, I found the test case, it simply involves more than one directory and --delete: rsync -av --delete remhost:'bin lib' . With this command I get 3 done messages: receiving file list ... done done done wrote 16 bytes read 7386 bytes 2960.80 bytes/sec total size is 4169245 speedup is 563.26 Without the --delete option I only get a single 'done' after the '...'. Hope that narrows it down enough to make it easy to find, -Lee ---begin quoted text--- From: Dave Dykstra [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: rsync 2.5.4 -v output (minor knit) Date: Thu, 14 Mar 2002 12:37:54 -0600 On Wed, Mar 13, 2002 at 03:44:36PM -0600, Lee Eakin wrote: I noticed a difference in verbose output that appears to be unintentional. it first prints 'receiving file list ...', then builds the list and prints 'done\n'. I haven't figured out the exact conditions yet, but with multiple remote sources (remote shell expands) it sometimes prints the 'done\n' message multiple times. I have a script I use to sync up my dot-files with multiple files and excludes that prints the 'done\n' line 16 times. I have not seen this, and I would appreciate a simple set of steps to reproduce it. I touched that code recently so I guess I should fix it. I tried rsync -av 'host:`echo dir1/*`' dir2 and that didn't do it. - Dave Dykstra ---end quoted text--- -- Lee Eakin - [EMAIL PROTECTED] Allen's Distinction: The lion and the calf shall lie down together, but the calf won't get much sleep. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
rsync 2.5.4 -v output (minor knit)
I noticed a difference in verbose output that appears to be unintentional. it first prints 'receiving file list ...', then builds the list and prints 'done\n'. I haven't figured out the exact conditions yet, but with multiple remote sources (remote shell expands) it sometimes prints the 'done\n' message multiple times. I have a script I use to sync up my dot-files with multiple files and excludes that prints the 'done\n' line 16 times. Is there a simple fix? People parsing the output of -v may want to be aware of this. I first saw it in 2.5.3. -Lee -- Law of Selective Gravity: An object will fall so as to do the most damage. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync daemon
The other option is to replace inetd with xinetd. It offers config options so you can tune the loop termination among other things. If you have a high-use rsync daemon then standalone is probably best. -Lee ---begin quoted text--- From: Dave Dykstra [EMAIL PROTECTED] Subject: Re: rsync daemon Date: Tue, 19 Dec 2000 10:10:46 -0600 I noticed this same problem on my redhat 6.2 machine last week. Check /var/adm/messages. Mine reported inetd[415]: rsync/tcp server failing (looping or being flooded), service terminated for 10 min I could see no way to configure Linux inetd to avoid that, so I ended up starting rsync as an independent daemon out of /etc/rc.d/rc3.d. - Dave Dykstra ---end quoted text--- -- Experience is what you get when you don't get what you want.
