similar to: rsync occassionally issues the message "rsync error: unexplained error (code 255) at main.c(1506) [generator=3.0.4]"

https://bugzilla.samba.org/show_bug.cgi?id=6461 Summary: rsync occassionally issues the message "rsync error: unexplained error (code 255) at main.c(1506) [generator=3.0.4]" Product: rsync Version: 3.0.4 Platform: Sparc OS/Version: Windows XP Status: NEW Severity: normal

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. 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

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

Here's another scratch for an itch I've been having with rsync (and there's also a Debian bug report about it). When doing: rsync -e ssh bla remote:foo if there's no ssh agent or such, ssh will ask for a password or passphrase. If you then hit ctrl-C, rsync will terminate, but the shell will not echo as rsync has killed ssh before ssh had a chance to restore the termio

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

http://bugzilla.mindrot.org/show_bug.cgi?id=119 ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:22 ------- what is the timeout issue? timeouts can be caused by filters that maintain connection state and have timeouts; or TCP keepalives or ??? this should probably be "invalid" ------- You are receiving this mail because: ------- You are the assignee for the

http://bugzilla.mindrot.org/show_bug.cgi?id=119 Summary: Occassionally, SSH failed to connect and timeout after 2 hrs! Product: Portable OpenSSH Version: older versions Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo:

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

Hello, I like to use rsync to transfer over mine and other peoples ever changing mail folder onto a remote server. My Server (FreeBSD 5.4) RSYNC Version is: 2.6.6 Protocol Version 29 My Client (OSX 10.4.2) RSYNC Version is: 2.6.3 Protocol Version 28 I use this command rsync -vvv --progress --stats --recursive --times \ --perms --links \ --delete /test/my?email?folder/*

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:

I'm using samba 2.2.3a as fileserver and domaincontroller for 12 NT4-clients (sp6a) and occassionally - when a user tries to logon - there comes the following messages on the nt-client: - No Windows NT Domain Controller is available for domain XXXX. There are currently no logonservers available to service the logonrequest. - and - server-side profile not available. The OS tries to log you on

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.

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

From: Joerg Roedel <jroedel at suse.de> Add the infrastructure to handle #VC exceptions when the kernel runs on virtual addresses and has a GHCB mapped. This handler will be used until the runtime #VC handler takes over. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/segment.h | 2 +- arch/x86/include/asm/sev-es.h | 1 + arch/x86/kernel/head64.c

From: Joerg Roedel <jroedel at suse.de> Add the infrastructure to handle #VC exceptions when the kernel runs on virtual addresses and has a GHCB mapped. This handler will be used until the runtime #VC handler takes over. Since the handler runs very early, disable instrumentation for sev-es.c. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/realmode.h | 3

Rsync-2.5.2 does not gracefully report connection and transfer errors and always properly return with a non-zero exit code, despite many assurances to the contrary in the code and commit logs. It seems a kludge to handle a special case of lost connections to older servers was FAR too aggressive! With '-vvv' I also print the source of the exit_cleanup() call, and optionally with

From: Joerg Roedel <jroedel at suse.de> Send SIGBUS to the user-space process that caused the #VC exception instead of killing the machine. Also ratelimit the error messages so that user-space can't flood the kernel log. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/sev-es.c | 32 +++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9

From: Joerg Roedel <jroedel at suse.de> Install an exception handler for #VC exception that uses a GHCB. Also add the infrastructure for handling different exit-codes by decoding the instruction that caused the exception and error handling. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/Kconfig | 1 + arch/x86/boot/compressed/Makefile

From: Joerg Roedel <jroedel at suse.de> Install an exception handler for #VC exception that uses a GHCB. Also add the infrastructure for handling different exit-codes by decoding the instruction that caused the exception and error handling. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/Kconfig | 1 + arch/x86/boot/compressed/idt_64.c