Re: Rsync 2.5.5 hangs
Never mind... upgrading to ssh3.0.2pl1 fixed the problem. Thanks anyways, Rich -- 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: Status Query - Please respond - Re: Patch to avoid 'Connection reset by peer' error for rsync on cygwin
On 10 May 2002, Max Bowsher <[EMAIL PROTECTED]> wrote: > The problem was especially severe here, because rsync didn't even > close the socket in these cases - it would write its last data, then return a > couple of times, and exit(). It should not matter: The function _exit terminates the calling process "immediately". Any open file descriptors belonging to the process are closed; any children of the process are inherited by process 1, init, and the process's parent is sent a SIGCHLD signal. > We could have a shutdownsocket(). Is it worth it for just for 2 lines of code? > shutdown(fd, SHUT_WR); > close(fd); Yes, because (if this is really necessary) then it's a workaround for a platform bug and so not obvious. After thinking about it a bit more I'm somewhat inclined to call it a bug in Cygwin and try to get them to fix it. > PS: Someone mentioned that 2.5.6 has branched in CVS. I'm a bit of a > CVS newbie unfortunately - what is the command for 'what branches > exist in the repository?' "cvs log" or http://cvs.samba.org/ will show you all the tags and branches. But at the moment there is only really one branch. -- Martin -- 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: Updating the docs/help on the default remote shell
On 3 May 2002, Wayne Davison <[EMAIL PROTECTED]> wrote: > Since rsync can now be configured with a different default remote shell > than "rsh", I think the docs should be updated a bit. Anyone object to > these changes? Looks good. -- Martin -- 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: [PATCH] rsync kills all user processes on fork failure
On 9 May 2002, Bob Byrnes <[EMAIL PROTECTED]> wrote: > On May 9, 4:51pm, [EMAIL PROTECTED] (Dave Dykstra) wrote: > -- Subject: Re: [PATCH] rsync kills all user processes on fork failure > > > > What's the best fix against the current CVS? Should we back out the > > previous fix because that one only solved half the problem? Somebody > > please provide an updated patch. > > > -- End of excerpt from Dave Dykstra > > I've appended an updated patch that can be applied to the current CVS. > > Description: > > -- Be extra careful: reject any negative pid in do_fork(), > not just -1 (since other negative values would also be > harmful if they were ever passed to kill, even though > such values should never occur). OK > -- Expand all_pids[] dynamically as needed in do_fork(), to > avoid any possibility of overflow. I can't see any situation in which that would happen. I can understand being defensive, but this seems like overkill. > -- Prevent kill(-1, SIGUSR2) in main.c; this is independent of > the interaction between do_fork() and kill_all(), which > involves SIGUSR1. Good. -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
"Unexplained error code xxx" in rsync-2.5.5
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 be always set to/left at 0, so the error slips through. I cannot investigate further, because i'm under pressure. So i ask you. This is a local copy operation: rsync -aC --exclude=README --exclude=Makefile . /u/tmp/bla Is there a child process forked for a local copy at all ? Another problem in main.c/wait_process(). A call to WEXITSTATUS(*status) must only happen, when WIFEXITED(*status) returns true. Else, WIFSIGNALED(*status) could be true, in which case the process was terminated by a signal. One has to extract the signal number using WTERMSIG(*stat)... and so on. There is also WIFSTOPPED() and WIFCONTINUED(). (mk) -- Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47 >> Im prämotorischen Cortex kann jeder ein Held sein. (bdw) << -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
minor error in "stderr & stdout" web site FAQ
Hello, There appears to be an error in the stderr redirection of the crontab rsync entry. In Bourne shell and compatibles (crontab entries are run by the Bourne shell) redirections are processed from left to right and "2>&1" redirects the stderr to the same location stdout is currently directed and not to stdout. Hence: cmd 2>&1 > log directs stderr to the terminal and stdout to the file log. But: cmd > log 2>&1 directs stdout to log and stderr to the same location stdout is current redirected, the log file. Here is a suggested patch for the FAQ on the web site at http://samba.anu.edu.au/rsync/FAQ.html --- rsync.faq.orig Sun May 12 16:04:12 2002 +++ rsync.faq Sun May 12 16:11:25 2002 @@ -17,10 +17,11 @@ they appear on stderr at the local computer. rsync can't intercept them. If you have a problem with scripts or cron jobs that produce stderr then I -suggest you use your shell to redirect stderr to stdout. For example you +suggest you use your shell to redirect stderr and stdout. For example you could do a cron line like this: -0 0 * * * /usr/local/bin/rsync -avz /foobar /foo 2>&1 > logfile +0 0 * * * /usr/local/bin/rsync -avz /foobar /foo > logfile 2>&1 -this would send both stderr and stdout to "logfile". The magic -bit is the "2>&1" which says to redirect stderr to stdout. +this would send both stderr and stdout to "logfile". The magic bit is the +"2>&1" which says to redirect stderr to to the same descriptor to which +stdout is currently directed. All the best, Mike -- __ __ _ _ ___ ____ ___ _ ___ ____ | \/ (_| | _ / _ \ | ___| | / _ \/ _ \| |_ _ _ _/ \/ \ _| | | |\/| | | |/ | ___| | _| | |_| __| ___| __| \/ \/| O | O / _ | |_| |_|_|_|\_\\___| |_| |\___|\___||\_/^\_/\___/\___/\___| -- 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: [PATCH] rsync kills all user processes on fork failure
On May 12, 3:43am, [EMAIL PROTECTED] (Martin Pool) wrote: -- Subject: Re: [PATCH] rsync kills all user processes on fork failure > > + -- Expand all_pids[] dynamically as needed in do_fork(), to > + avoid any possibility of overflow. > > I can't see any situation in which that would happen. I can understand > being defensive, but this seems like overkill. > -- End of excerpt from Martin Pool I don't think it can happen currently; I was concerned about the scenario in which rsync evolves to spawn more subprocesses, and eventually (when there are more than 10), the failure mechanism will be (very) non-obvious. Certainly this is unlikely (the array is generously sized), but the complexity cost to completely prevent the problem is tiny: about a half dozen lines of code, so I think it is worth considering. Clearly there is no performance cost, compared to fork(). If you think Realloc is overkill, I'd at least add a check to detect overflow and panic rather than just stomping past the end of the array. The magical constant "10" is hidden pretty deeply in the low-level code. But Realloc is not that much harder, and then there is no limit whatsoever. Thanks for taking the kill(-1, SIGUSR2) fix: that is by far the most important part. Bob Byrnese-mail: [EMAIL PROTECTED] Curl Corporation phone: 617-761-1200 400 Technology Square, 8th Floor fax:617-761-1201 Cambridge, MA 02139 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Announcement: Graphical frontend
(I've talked about this before, but now my ideas are becoming reality) rsync has many uses. I think it would be a good idea to uses rsync to transfer files in stead of http and ftp. I hope that the current filemanagers and download managers will support rsync in the future. Untill then people can use my graphical frontend. It's still beta, but it's actually useable. A couple of friends are using it to download files from me. It's written in PHP-GTK, and has been tested in Linux and Windows. Please test it, and tell me what you think. http://myplace.dk/WINrsync I hope you like the idea, I could use some help. Both for the php and gtk, but also the interface, and how the frontend should interact with rsync. -- Mvh. Niels Andersen -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RFC for feature request
Hi. Recently at work we've begun using rsync to sync up our development baseline area between our office in Houston, and the one in Gatwick. We use rsync quite extensively, and are quite happy with it, but have run into a bug discussed by Dave Dykstra in the "Discussion/2214" entry on the rsync website: http://lists.samba.org/pipermail/rsync/1999-October/001440.html Basically, due to the way fnmatch does it's matching for excludes, something we thought we had excluded got clobbered when we didn't want it to be touched. The issue is that fnmatch expects to match from the beginning, but we were trying to match deeper in the directory structure. Once we found Dave's comments, we were able to get around the issue, but it got me to thinking. His parting words were: Someday include/exclude's semantics and implementation should be completely redone. I'm very familiar with Perl, and Perl regular expressions, as I use both constantly. At http://www.pcre.org you will find the Perl Compatible Regular Expression library. What I'd like to propose [and am willing to work on in my "free" time], is to implement: a) a new command-line option [or two] that allow for the fnmatch behavior [default] or the use of the PCRE library's RE engine. b) the functions to implement the file matching bits needed by include / exclude using the pcre library functions. However, before I delve into doing this, I'd like some comments: 1) Has the above bug already been worked out? 2) Is anyone working on such a re-write / addition? Doesn't have to be using "pcre", but I'd hate to "waste" time implementing it if someone else is already working along the same lines. 3) How are things like this normally handled? The reason I would prefer to do this as an additional option is that it will allow existing scripts to continue unchanged, while allowing those who want to use the pcre features can do so. Thoughts? Comments? Concerns? Cheers, Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
(no subject)
Subscribing to rsync -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
