From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002 Firefox/0.10.1 Description of problem: After updating to the 20041004 development tree, the rsync server no longer seems to be working correctly. Clients connect the connection fails immediately: katratzi> rsync -az --delete wintermute::fedora-core-linux . ############################################################################### Welcome to the Wintermute rsync Server! ############################################################################### rsync: connection unexpectedly closed (4 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(359) katratzi> Unfortuantely, downgrading to the older rsync-2.6.3-0.pre2.i386.rpm doesn't help so it's probably not with rsync but something else (glibc?) Version-Release number of selected component (if applicable): rsync-2.6.3-1 How reproducible: Always Steps to Reproduce: 1. configure an rsync server 2. try to rsync from it 3. Additional info:
All I can tell from the information above is that the remote rsync server closed the connection. To find out what's going on you're going to have to look at the logs on the remote server. The remote rsync should have said something before closing the connection. If you don't administer the remote server, you'll need to contact the server administrator.
I run the server. The problems is nothing gets logged except the connection attempt by the client: Oct 13 15:21:17 wintermute rsyncd[8752]: rsync on fedora-linux-core from katratzi.sr.unh.edu (132.177.241.101) Oct 13 15:21:39 wintermute rsyncd[8753]: rsync on fedora-linux-core from doolittle.sr.unh.edu (132.177.241.102) I can't gdb rsync because with --daemon --no-detach, it still forks for every connection. Nothing gets logged but the children seem to die instantly. There are no selinux errors or anything like that. I just tried removing and reinstalling rsync as a test server on another machine works fine. I'm at a loss.
I should also add the clients can get file lists: katratzi> rsync wintermute::fedora-linux-core ############################################################################### Welcome to the Wintermute rsync Server! ############################################################################### drwxr-xr-x 4096 2004/05/17 09:14:17 . drwxr-xr-x 4096 2004/03/03 16:13:48 1 drwxr-xr-x 4096 2004/05/14 07:18:24 2 drwxr-xr-x 4096 2004/07/23 09:34:47 development drwxr-xr-x 4096 2004/10/10 23:12:30 test drwxr-xr-x 4096 2004/05/18 12:32:22 updates katratzi> But when I switch to actually getting the files, it dies: katratzi> rsync -az -v -v -v -v -v -v wintermute::fedora-linux-core opening tcp connection to wintermute port 873 ############################################################################### Welcome to the Wintermute rsync Server! ############################################################################### (Client) Protocol versions: remote=28, negotiated=28 receiving file list ... rsync: connection unexpectedly closed (4 bytes received so far) [receiver] _exit_cleanup(code=12, file=io.c, line=359): entered rsync error: error in rsync protocol data stream (code 12) at io.c(359) _exit_cleanup(code=12, file=io.c, line=359): about to call exit(12) katratzi>
Can you try running the rsync server under strace? Use the -f option to trace the child server as well as the parent, and put the output in a file with -o.
Created attachment 105162 [details] strace of rsync Thanks. Here's the strace. The child processes are segfaulting...
Ok, it does a chroot to /space/ftp/redhat/fedora , then it attempts to open a bunch of normal system files ( /etc/localtime /etc/passwd /etc/ld.so.cache ... /usr/lib/libnss_nis.so.2 ) and then it segfaults. Hmm. What happens if you modify the server config to not chroot? Can you attach the rsh server configuration to the bug?
Created attachment 105171 [details] rsyncd.conf Here's the rsyncd.conf file. One of the first things I tried was disabling chroot but that didn't help.
Created attachment 105172 [details] strace of rsync with chroot commented out
Oddly, rsync still does a chroot. I set up an rsync server similar to yours (I had to change the pathnames, and I don't have the directory contents. . .), and it doesn't fail for me. I guess I'll have to try replicating the contents too. Is this a straightforward mirror of download.fedora.redhat.com ? Hmm. Come to think of it, you might also want to try running memtest86 on your machine. We can't rule out a hardware problem.
It is a mirror of mirror.linux.duke.edu which I believe is a mirror of download.fedora.redhat.com. I'll try some more experiments here nfs mounting the content to a different machine and setting up a server on it.
The default for chroot is yes. Setting chroot to no makes everything work on the initial problem system wintermute. If I automount the same directory structute to another system and set up the rsyncd.conf file appropriately and set chroot to yes, it works fine. If I then modify wintermute so that it uses the automounted directory paths it still fails. Looks like something is broken on just wintermute. I compared RPMS between the two systems and nothing stood out. One other thing to note. I can successfully rsync wintermute:: to get a list of the modules. I can rsync wintermute::fedora-linux-core and get a list of the file structure of module fedora-linux-core (or any modules for that matter). So it's partially working. If I just add -a to get a complete file structure listing, it fails. I don't know what else to try.
Got exactly the same problems on a Fedora Core 2. Adding the following line use chroot = no in /etc/rsyncd.conf solved the issue...
Upgrading the system to FC3 fixed this for me. I can now have chroot set to yes and systems can still connect and transfer files fine.
Have you had this problem with any version of rsync shipped in Fedora Core 3 or later? Ifnot, can I close this bug?
This failure was probably caused by the LDAP code crashing when getpwuid() calls were made from inside a chroot environment. As long as that library has been fixed, this crash should have gone away.
No reply in a long time. Closing.