rsync crashing under centos 4

[Joe Pruett]

> 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?

that is the whole point of the nsswitch magic.  it dynamically loads the
libraries as directed by the nsswitch.conf file.  the same program can
work on machines that use nis, ldap, local files, databases, etc.  from my
testing, there is nothing that rsync can do that will help other than not
do getpwuid type calls when chroot'ed.  i'm going to be submitting to
redhat and see if i can find the actual bug in libc but the nss code is
quite twisty.  previous versions of nss worked fine in chroot by
gracefully failing, so it is some new tweak in the nss code that has
broken things.