rsync crashing under centos 4

[John Van Essen]

On Thu, 10 Mar 2005, Joe Pruett <joey at clean.q7.com> 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:

  http://www.mail-archive.com/rsync@lists.samba.org/msg12557.html

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/libnss_compat.so.2", 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 umn.edu>