[Bug 2572] --address switches to daemon mode
https://bugzilla.samba.org/show_bug.cgi?id=2572 --- Additional Comments From [EMAIL PROTECTED] 2005-04-04 22:56 --- Created an attachment (id=1137) --> (https://bugzilla.samba.org/attachment.cgi?id=1137&action=view) Allow the --address option to be parsed in client mode. This change to option.c re-allows the use of --address in the client (for use when connecting to an rsync daemon). -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 2572] --address can no longer be used with client mode
https://bugzilla.samba.org/show_bug.cgi?id=2572 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|--address switches to |--address can no longer be |daemon mode |used with client mode --- Additional Comments From [EMAIL PROTECTED] 2005-04-04 22:59 --- Thanks for pointing out my mistake. I've checked-in a fix for this. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
increasing throughput over slow-but-fat WAN links?
Hi there We have a world-wide WAN network that we are running rsync over. It all works - but the throughput of any one rsync connection is limited by the latency on our inter-continental links. e.g a site may have a 4Mbs link, but a single rsync job can only get 1.5Mbs of the bandwidth. Running 3-5 rsync jobs in parallel gets around that limit and obviously allows us to saturate a particular pipe (and yes - we want to :-), but that requires hand-crafting schedules of bunches of rsync jobs in order to achieve that. And we've got heaps - and want to open this up to our users to define themselves - so such hand-crafting will be going the way of the Dodo ;-) What would be better is if one rsync job could be "chopped up" into a bunch of "mini-"rsync jobs - and then a separate rsync run for each. e.g. an rsync job mirroring 10Gb of data in 1,000,000 files would be best split into 5 separate jobs - each mirroring 200,000,000 files. That way we get to saturate the pipes and get the jobs done quicker. So I'm about to see if I can figure out some way to do this in perl - but was wondering if anyone else has already done this? Perhaps doing a "rsync -nv" first and sorting the output, then splitting into "X" separate jobs? Even a rough guess at it could make a difference. -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 2572] New: --address switches to daemon mode
https://bugzilla.samba.org/show_bug.cgi?id=2572 Summary: --address switches to daemon mode Product: rsync Version: 2.6.4 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] This is a inadvertent and suboptimal change of behavior in 2.6.4 The are plenty of reasons why one might want to bind _the client_ to a different interface on a multihomed system. I personally use it depending on the which of my two upstream links has more free capacity. Please revert the behavior. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- 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: HP-UX 11i and largefiles on rsync
On Apr 4, 2005 10:33 AM, I wrote: > I've also noticed that "make test" fails every rsync daemon mode test > on HP-UX. I'm still investigating but it looks like a either typecast > in socket.c getsockname or a problem with "htonl(INADDR_LOOPBACK)" (of > all things) leads to a failure to bind the socket when run in daemon > mode. I found the problems-- they were limited to the test code only so it doesn't look like rsync itself is the problem. However, I have not yet back-ported the changes I made to my simplified test case into rsync so there may still be something there that needs fixing. The problems were: 1) In socket.c there's the line "sock2.sin_family = PF_INET;" but no corresponding line for the other socket "sock". The connect() blows up on HP-UX with an address family error since it's still set to 0. 2) In the same file, neither socket ever gets a TCP port assigned, so connect() fails on HP-UX. The same code works great on my Linux host, since Linux helpfully populates these missing values. Would you like a suggested patch or is the above good enough? -- Steve -- 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 is flaky going to Penang
The internet connection is probably flaky and erratic. What we do between interior of China and US In China is a box whose only purpose is an rsync host. >From China to that box is at LAN speeds and is dependable. To or from that box to the US is at bad internet speeds and is not dependable. Within the US transfers are controlled from whereever I can log in and get a reasonable conection. (I've got more or less up-to-date info at 2 or 3 different locations stateside) You may be able get something from the following. The important thing is to not expose your primary sources and destinations to the vagaries of the internet. Disk is cheap. [edited and sanitized] (and no apologies for bad code herein) [EMAIL PROTECTED] root]# time ./rsync-XXX-dwg ; date ; date -u real 0m13.706s Thu Mar 31 12:10:57 CST 2005 C as in China, not Central Thu Mar 31 04:10:57 UTC 2005 [EMAIL PROTECTED] root]# cat rsync-XXX-dwg #!/bin/bash # rsync-XXX-dwg XXX_Drawings/ title/ mkdir -p /tmp/rsync ; echo `hostname` > /tmp/rsync/OPENED rsync -a --password-file=/etc/rsync.secrets/XXX-dwg --timeout=750 \ /tmp/rsync/OPENED [EMAIL PROTECTED]::rsync-XXX-dwg/ for name in title XXX_Drawings ; do rsync -a --password-file=/etc/rsync.secrets/XXX-dwg --timeout=750 \ /home/dwg/$name [EMAIL PROTECTED]::rsync-XXX-dwg/ done mkdir -p /tmp/rsync ; echo `hostname` > /tmp/rsync/CLOSED rsync -a --password-file=/etc/rsync.secrets/XXX-dwg --timeout=750 \ /tmp/rsync/CLOSED [EMAIL PROTECTED]::rsync-XXX-dwg/ [EMAIL PROTECTED] root]# du -s /home/dwg/XXX_Drawings/ 12618920 /home/dwg/XXX_Drawings [EMAIL PROTECTED] /root]# time ./rsync-XXX-dwg ; date ; date -u real 1m12.449s <-- IDE to same IDE (lots of seeks?) receiving file list ... 50246 files to consider CLOSED 7 100% 6.84kB/s 0:00:00 (1, 0.0% of 50246) OPENED 7 100% 0.49kB/s 0:00:00 (2, 0.0% of 50246) [snip] sent 420 bytes received 2101460 bytes 2355.05 bytes/sec total size is 12642359798 speedup is 6014.79 real 14m52.839s <-- This is over a BAD internet connection* Wed Mar 30 22:32:16 CST 2005 C as in Central, not China Thu Mar 31 04:32:16 UTC 2005 *BAD Internet. 2 tries to SSH directly, both timed out trying to connect. (SSH'd to a box at big boss's home (DSL) and then from there. Different routes) This is acceptable transfer over a sporadically available connection! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Monday, April 04, 2005 5:41 PM To: [EMAIL PROTECTED]; rsync@samba.org Subject: rsync is flaky going to Penang Hello, We are experiencing flaky behavior from rsync when attempting to rsync directories/files to a server in Penang. Several times the job seems to hang and never completes. Penang then is therefore missing a lot of required cad files.Have any of you experienced the same thing and what did you do to fix the problem? Does anyone know of a better tool to use? We chose rsync after rdist gave us problems. Perhaps were missing an important flag in our rsync commands but I think it s set up correctly. Thanks and Best Regards, Jackie Wright Agilent Technologies - WSD R&D IT Engineer Telnet: 435-6653 or (408) 435-6653 Cell: (510) 825-7638 Fax: (408) 435-4803 -- 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 is flaky going to Penang
Hello, We are experiencing flaky behavior from rsync when attempting to rsync directories/files to a server in Penang. Several times the job seems to ‘hang’ and never completes. Penang then is therefore missing a lot of required cad files. Have any of you experienced the same thing and what did you do to fix the problem? Does anyone know of a better tool to use? We chose rsync after rdist gave us problems. Perhaps we’re missing an important flag in our rsync commands but I think it’s set up correctly. Thanks and Best Regards, Jackie Wright Agilent Technologies - WSD R&D IT Engineer Telnet: 435-6653 or (408) 435-6653 Cell: (510) 825-7638 Fax: (408) 435-4803 -- 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: HP-UX 11i and largefiles on rsync
On Apr 4, 2005 10:33 AM, Steve Bonds wrote: > How's this for a plan? > 1) On 64-bit HP-UX systems, build a 64-bit binary (above lseek64 fix > will be needed) > 2) On 32-bit HP-UX systems, build using mktemp() After more pondering, I think this would be a bad idea. The only time a 64-bit binary is likely to work would be if using the optionally purchased HP C/ANSI C compiler. Using gcc on HP-UX seems to have lots of 64-bitness problems. So how's this for a revised plan? 1) On HP-UX systems, build using mktemp() 2) Put a warning in the HP-UX section of the INSTALL file about this necessity -- Steve -- 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 2.6.4 Multiplexing Overflows when File Name Too Long (cwRsync)
Benjamin Watkins wrote: I will let you know how the patch works for me. I am currently running it from Workstation 1 to Server 1. After more extensive testing with this patch, I can confirm that it does indeed resolve this issue for me under Cygwin. If Tev repackages his cwRsync package, I would recommend he applies this patch as this problem appears to be particularly noticeable with Cygwin. He should also use the most recent cygwin1.dll in order to resolve the exit code problem. I am assuming for simplicity's sake that Tevfik Karagülle is male, so my apologies if this is incorrect. -Ben : ) -- 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: HP-UX 11i and largefiles on rsync
On Apr 1, 2005 5:30 PM, Wayne Davison wrote: > I attempted a fix for this by having the code not use mkstemp() if > open64() was around but mkstemp64() was not. However, not having any HP > systems around to test this on, I never heard if this was helpful or > not. Apparently not. Don't you wish there were a good PA-RISC emulator out there? HP-UX is so strange, I can't imagine writing software for HP-UX without a build/test system. > I'd prefer to add rules to configure that don't require trying to write > a large sparse file or to use the O_LARGEFILE kluge, but I'm open to > suggestions on whether creating a 64-bit binary is better than just > disabling HAVE_SECURE_MKSTEMP for HP-UX. I think the latter would > probably be good enough, if we just want to go that route. What's the > best way to detect HP-UX, anyway? If we can avoid using mktemp(), I'd like to since relying on file locking for security on a UNIX system is potentially dangerous. I think the chances of creating an exploitable security problem by using mktemp() in the same directory as the destination file are pretty slim, but it's possible. My main concern with a 64-bit binary would be compatibility if the binary were copied onto a system running 32-bit HPUX. These are becoming quite rare, so this is less of a concern. The comp.sys.hp.hpux FAQ number 6.2.7 has this to say on detecting HPUX: - Subject: 6.2.7 How can I detect the HP-UX version at compile time? The below macro sequence allows you to figure out the HP-UX major version number: #include #if defined(PRIV_PSET) #define _hpux_11i #elif defined(PRIV_SPUCTL) #define __hpux_11x #elif defined(PRIV_SERIALIZE) #define __hpux_10x #elif defined(PRIV_SETRUGID) #define __hpux_9x #endif (Added by Ian, 05/02/02) - >From either >http://web.archive.org/web/20030324214118/faqs.org/faqs/hp/hpux-faq/ or http://www.faqs.org/faqs/hp/hpux-faq/. This was also useful, since it could be used to limit building a 64 bit binary only on 64-bit systems: - Subject: 5.5.1 How can I tell if I have a 32-bit or 64-bit kernel? First off, in all versions of HP-UX prior to 11.00, the kernel is always 32-bit. That being said, on 11.x systems, there are several ways to determine whether you're running a 32 or 64 bit kernel... >From the command-line = $ getconf KERNEL_BITS ... trimmed ... (Thanks to Brian Hackley <[EMAIL PROTECTED]> and Ian) (Added by Ian, 04/19/01) - The above can also be accomplished via C code using sysconf(). Finally, I found a problem trying to build a 64-bit HPUX binary using the current configure script. syscall.c uses the results of "AC_CHECK_SIZEOF(off64_t)" to infer the existence of lseek64(). This fails on HP-UX since off64_t is defined, but lseek64() doesn't exist. I'd suggest a direct check for lseek64() instead of this inference, if possible. How's this for a plan? 1) On 64-bit HP-UX systems, build a 64-bit binary (above lseek64 fix will be needed) 2) On 32-bit HP-UX systems, build using mktemp() I've also noticed that "make test" fails every rsync daemon mode test on HP-UX. I'm still investigating but it looks like a either typecast in socket.c getsockname or a problem with "htonl(INADDR_LOOPBACK)" (of all things) leads to a failure to bind the socket when run in daemon mode. -- Steve -- 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] linux <-- mac
Hello. >From googling, I can see that this subject came up back in '03, but I've not seen any solutions. Is it possible to run rsync on a Linux machine, pulling data from a Mac ? I'm not concerned about resource forks. I can [s]cp the files just fine. This Mac machine has been rsync'ing successfully with other Macs. When I try it (w/ v.2.6.4 on the Linux end), it takes ~2 orders of magnitude longer than it should, & gives me the replicated directory tree, but with all 0-byte files, & many extraneous *dirattr* files . Thanks. Gary R. Webster -- 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: Always exitcode 256 under Cygwin with rsync 2.6.4
Joost van den Broek wrote: I can confirm too that this has solved the problem for me. It's time for a new cwRsync release :) - Joost If Tev is going to release a new cwRsync, I might ask that he adds the patch Wayne made for the problem I experienced with multiplexing errors. This appears to have resolved the problem for me, though I am doing further testing to confirm this. -Ben : ) -- 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: Always exitcode 256 under Cygwin with rsync 2.6.4
On Monday 4 April 2005 16:39, Paul Haas wrote: > > If I understand the problem, it looks like it is fixed in Cygwin 1.5.14-1, > which was released sometime on Saturday. > > http://cygwin.com/ml/cygwin/2005-04/msg00073.html > > The Cygwin 1.5.14-1 announcement includes this change: > > - cgf: Right shift exit code by eight when process is not started in a > cygwin environment. > > Which sounds like the fix to your problem, although it is hard to tell, > since you didn't say what Cygwin version you were running. I can confirm too that this has solved the problem for me. It's time for a new cwRsync release :) - Joost -- 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: Always exitcode 256 under Cygwin with rsync 2.6.4
Paul Haas wrote: On Sun, 3 Apr 2005, Wayne Davison wrote: On Mon, Apr 04, 2005 at 07:28:02AM +0200, Joost van den Broek wrote: When you just give an empty rsync command, it should also exit with an exit code (1). But the errorlevel gets set to no. 256 instead. As mentioned in the other message that brought this up, I assume that this is something wrong with the cygwin version (perhaps in how it was compiled?). Rsync is exiting with all the right codes under Linux. If I understand the problem, it looks like it is fixed in Cygwin 1.5.14-1, which was released sometime on Saturday. http://cygwin.com/ml/cygwin/2005-04/msg00073.html The Cygwin 1.5.14-1 announcement includes this change: - cgf: Right shift exit code by eight when process is not started in a cygwin environment. Which sounds like the fix to your problem, although it is hard to tell, since you didn't say what Cygwin version you were running. -- Paul Haas [EMAIL PROTECTED] I can confirm that the binary I compiled using this version does give the proper exit codes. It appears this was the root of the exit code problem. -Ben : ) -- 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: Always exitcode 256 under Cygwin with rsync 2.6.4
On Sun, 3 Apr 2005, Wayne Davison wrote: On Mon, Apr 04, 2005 at 07:28:02AM +0200, Joost van den Broek wrote: When you just give an empty rsync command, it should also exit with an exit code (1). But the errorlevel gets set to no. 256 instead. As mentioned in the other message that brought this up, I assume that this is something wrong with the cygwin version (perhaps in how it was compiled?). Rsync is exiting with all the right codes under Linux. If I understand the problem, it looks like it is fixed in Cygwin 1.5.14-1, which was released sometime on Saturday. http://cygwin.com/ml/cygwin/2005-04/msg00073.html The Cygwin 1.5.14-1 announcement includes this change: - cgf: Right shift exit code by eight when process is not started in a cygwin environment. Which sounds like the fix to your problem, although it is hard to tell, since you didn't say what Cygwin version you were running. -- Paul Haas [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
Re: Always exitcode 256 under Cygwin with rsync 2.6.4
Wayne Davison wrote: On Mon, Apr 04, 2005 at 07:28:02AM +0200, Joost van den Broek wrote: When you just give an empty rsync command, it should also exit with an exit code (1). But the errorlevel gets set to no. 256 instead. As mentioned in the other message that brought this up, I assume that this is something wrong with the cygwin version (perhaps in how it was compiled?). Rsync is exiting with all the right codes under Linux. ..wayne.. It is curious to note that, under Posix, it is impossible to exit with return code 256, as the return code is an 8 bit value. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
