similar to: Unexplained error

To Whom It May Concern: Below is a patch, that I have used to eliminate the unexplained errors in the rsync program. I was able to trace the problem to the order in which the sigchld_handler and wait_process routines were executed. If sigchld_handler executes first it retrieves the status that wait_process needs to indicate proper rsync termination. The code below allows the sigchld_handler to

I believe I have found the cause of the unexplained error (code ??) at main.c(line #). In the version I'm running 2.5.2 (obtained from the Free Software Foundation) the line number is 576. It appears the root cause is related to a race condition associated with the termination of child processes. If the signal handler for SIGCHILD is executed, as the result of a child termination, before the

Hi I want to use pre-xfer exec function in rsync for permition checking. In my Linux boxes, it successed. But today, I tried to put them in my FreeBSD box, it failed. I've checked the log, but found the pre-xfer exec returns always be -1, which means waitpid failed to get the return status. After doing a little ugly patch for the wait_process function as follow, pre-xfer works again.

Hi. We sometimes/often get such errors. It occures in main.c/client_run(). I investigated further and found, that the waitpid() in main.c/wait_process() exits with -1, errno = ECHILD, which means "No children". *status can contain garbage in such cases - but not always. It happens under Solaris-2.5.1/SPARC. It (ECHILD) also happens on other Solaris versions - but there *status seems to

I compiled rsync-2.5.5 on HPUX 11.11, using the +DA2.0W and +O3 options. invoking a simple rsync to transfer a file works (I ran a diff on the file, no changes) e.g: sdx1 214: ./rsync --rsh='/usr/bin/ssh -x' --rsync-path=/usr/local/src/rsync-2.5.5/rsync /scratch/chuck/tmp.test sdx2:/scratch/chuck However, adding the -a option yields an unexplained error: (In all of the following cases

A google search on this problem did not show any matches, so I'll take the chance that someone on this list might consider it an rsync problem. In a nutshell, if rsync forks a child process to handle the transport (rsh in this case) it can hang in wait_process() forever waiting for that child process to die. Normally this would not be a problem. However, if the wrong packet is dropped

Author of the message didn't include rsync@lists.samba.org in the reply, and I think this message is in topic. -------- Original Message -------- Subject: Re: rsync windows -> unix still hanging :( Date: Mon, 30 Dec 2002 17:24:47 -0800 From: Jim Kleckner <jek_subs@kleckner.net> To: Mike Rubel <mrubel@galcit.caltech.edu> CC: cygwin@cygwin.com References:

Greetings. I'm not sure if this is the place or not, but I wanted to pass on this patch (against CVS as of today) to document two exit values that are used by rsync but not yet in the docs. Please let me know if there's a better place to send it. Many thanks to the developers and maintainers of rsync for all the excellent work! Jon Index: rsync.yo

Hi, Please try this patch below, I think it?ll solve the bug? Amir diff -U 5 -Nuir rsync-3.0.4/cleanup.c rsync-3.0.4.new/cleanup.c --- rsync-3.0.4/cleanup.c 2008-06-04 19:01:02.000000000 +0300 +++ rsync-3.0.4.new/cleanup.c 2009-03-29 09:45:04.000000000 +0300 @@ -98,11 +98,11 @@ static int unmodified_code = 0; SIGACTION(SIGUSR1, SIG_IGN); SIGACTION(SIGUSR2,

FYI, We've been using the 2.4.7pre1 release for several days now, with nary a hang problem. We haven't seen the EOF bug at all, which was what we upgraded for. This is with transfers of as much as 50GB to set up an initial mirror. The only thing we did was set timeout=0 -- which I guess is unnecessary. The semantics of this flag are a bit unclear. We thought was 'time since

In case others find this of value, I wrote a patch to rsync 2.5.6 to give rsync in --daemon mode the ability to run a pre-transfer and post-transfer command. These options handle our need to prepare a server to receive files and to do some processing after receiving files. The options for /etc/rsyncd.conf are pretransfer script = /some/command/to/run posttransfer script =

I had a friend run some Cygwin tests and we found that --modify-window=1 works just as well as --modify-window=2 on FAT filesystems to copy files from Unix and detect the difference in granularity. FAT filesystems always have timestamps that have an even number of seconds. On the other hand, NTFS filesystems can store the modification time down to the second, whereas previously people on this

Trying to figure out this problem. RSYNC maybe once a day or so will just hang and sit there... strace attached to the process produces the following... I wonder where the loop is. Anything I can do to help would be fabulous. Most of the time it works fine. Very strange. -- Mike gettimeofday({1022283618, 513186}, NULL) = 0 wait4(22167, 0xbffff9e8, WNOHANG, NULL) = 0 gettimeofday({1022283618,

Hi, In http://sources.redhat.com/ml/cygwin/2002-09/msg01155.html, I noted that the often-observed hangs of rsync under Cygwin were assuaged by a call to msleep(). After upgrading my Cygwin environment to rsync 2.5.6, I'm seeing these hangs again, not surprisingly given a CVS entry for main.c notes that this kludge was not harmless: Revision 1.162 / (download) - annotate - [select for

I'm working on trying to get rsync 2.5.6pre1 available for people to test more widely. I'm out of time for today, and I'm stuck on a problem that some machines on build.samba.org are showing on the 'chgrp' test. I can reproduce this on my home redhat 7.3 system too. It appears to be a timing problem because when I do strace -F -f on it the problem goes away. Everything seems

Initial problem: When running 'make test' the hands.test fails as indicated in problem #3711 and includes the line rsync error: unexplained error (code 63) at main.c(537) The code # changes each time the test is run. Using HP C-ANSI-C B.11.11.02. configure line: CFLAGS="-O" ./configure --prefix=/opt/local In tracking this down, this is what I found: In main.c a

As I reported a while back rsync doesn't handle metadata (permissions and ownership) in dryrun mode. I offered to make a patch and that offer still stands. I didn't have the time for it until now and want to pick it up again. I had some ugly hack back then but I want to redo it in a clean way. I would like some input on my thoughts. IMHO, it would be ideally if the check for dry_run

I'm using rsync 2.6.9 and rsnapshot 1.2.9 on Ubuntu 8.04. When using rsnapshot to backup a remote computer over ssh, I get the message rsync error: unexplained error (code 130) at rsync.c(271) [generator=2.6.9] ERROR: /usr/bin/rsync returned 130 while processing root@undertow:/ I looked at the source for rsync 2.6.9, and line 271 in rsync.c is just a comment. Furthermore, it is in the

I synchronized two backup servers within a local network which worked fluently, using rsync with the following parameters: rsync --archive \ --hard-links \ --delete \ --rsh="ssh -i $key_file" \ --copy-dest=/var/lib/backuppc \ --compress-level=9 \ --stats \ --human-readable \ --partial-dir=.rsync-partial \ --bwlimit=$bwlimit \ /var/lib/backuppc

https://bugzilla.samba.org/show_bug.cgi?id=1476 Summary: Unexplained timout at end of file transfer. Product: rsync Version: 2.6.2 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: ej.grace@imperial.ac.uk