On Tue, 15 Feb 2005, david blunkett <[EMAIL PROTECTED]> wrote:
>
> The use chroot=no certainly has a beneficial effect because rsync has
> started to work again.
>
> Here is (probably) the interesting bit of the debugging output before:
> What seems to happen is that it chroots, builds the file list and then tries
> to open all sorts of stuff that is impossible once chrooted. ...
You have an unusual situation in that you use the daemon as a receiver.
Rsync has gotten the file list from the sender and is probably starting
the process to split into a receiver and generator. That process may be
trying to access a bunch of stuff, can't get to any of it, and then SEGVs.
I doubt that the SEGV is the intended result...
Since you used 'ulimit -c unlimited', a 'core' file should exist in the
working directory when in segfaulted (/optics/archive/trouble I believe).
What does the backtrace output from gdb show?
I'm mystified why this error does not happen on your other rsync that
transfers an empty directory... What does an strace for that show that
is different from this one, I wonder?
--
John Van Essen Univ of Minn. Alumnus <[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
