rsyncd / firewall

John Van Essen vanes002 at umn.edu
Wed Feb 16 06:48:32 GMT 2005


On Tue, 15 Feb 2005, david blunkett <dav1dblunk3tt at hotmail.com> 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  <vanes002 at umn.edu>



More information about the rsync mailing list