rsync crashing under centos 4

John Van Essen vanes002 at
Fri Mar 11 18:10:53 GMT 2005

On Thu, 10 Mar 2005, Joe Pruett <joey at> wrote:
> the rsync in centos 4 (a recompile of rhel4) is version 2.6.3.  and under
> certain circumstances it will segfault when run in daemon mode.  i have
> tracked it down to the nss code in libc.  so this could be a general libc
> bug, but it is possible that rsync is doing things that don't help matters
> any.
> the problem manifests when you have chroot mode on (which seems to be the
> default), have files on the server owned by someone other than root, and
> request an rsync with -o enabled.  this causes the server process to try
> to call getpwuid for the file uid and things segfault. ...

A similar problem was reported back in February:

that manifested itself after an upgrade to Fedora Core 2.  It had worked
fine previously (on FC1, presumably).

That user (David Blunkett) provided an strace log that showed this:

[pid 27916] open("/usr/lib/", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 27916] stat64("/usr/lib", 0xfef74ac8) = -1 ENOENT (No such file or directory)
[pid 27916] --- SIGSEGV (Segmentation fault) @ 0 (0) ---

where it's trying to load a dynamically linked library and ends up
crapping out at the end.  So this is a problem with some run-time
dynamically linked library failing to load.   But why the delayed
load attempt?  Aren't these supposed to be resolved when the program
is initially loaded at run-time?

This has not been a problem in the past, AFAIK.

Perhaps some newer library is trying to be too clever for its own good.

As a workaround, maybe rsync could do a call to getpwuid() and getgrgid()
before doing the chroot to make sure it has the required library loaded?
        John Van Essen  Univ of Minn. Alumnus  <vanes002 at>

More information about the rsync mailing list