Bug 134544 - clients can no longer rsync
clients can no longer rsync
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: rsync (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
:
Depends On:
Blocks: FC3Target FC4Target
  Show dependency treegraph
 
Reported: 2004-10-04 11:20 EDT by Thomas J. Baker
Modified: 2014-08-31 19:26 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-24 11:30:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of rsync (59.60 KB, text/plain)
2004-10-13 16:20 EDT, Thomas J. Baker
no flags Details
rsyncd.conf (508 bytes, text/plain)
2004-10-13 18:36 EDT, Thomas J. Baker
no flags Details
strace of rsync with chroot commented out (33.10 KB, text/plain)
2004-10-13 18:37 EDT, Thomas J. Baker
no flags Details

  None (edit)
Description Thomas J. Baker 2004-10-04 11:20:47 EDT
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:
Comment 1 Jay Fenlason 2004-10-13 14:52:06 EDT
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. 
Comment 2 Thomas J. Baker 2004-10-13 15:37:27 EDT
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.
Comment 3 Thomas J. Baker 2004-10-13 15:40:26 EDT
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>
Comment 4 Jay Fenlason 2004-10-13 16:15:05 EDT
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. 
Comment 5 Thomas J. Baker 2004-10-13 16:20:24 EDT
Created attachment 105162 [details]
strace of rsync

Thanks. Here's the strace. The child processes are segfaulting...
Comment 6 Jay Fenlason 2004-10-13 16:45:50 EDT
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? 
Comment 7 Thomas J. Baker 2004-10-13 18:36:24 EDT
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.
Comment 8 Thomas J. Baker 2004-10-13 18:37:48 EDT
Created attachment 105172 [details]
strace of rsync with chroot commented out
Comment 9 Jay Fenlason 2004-10-14 14:40:18 EDT
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. 
Comment 10 Thomas J. Baker 2004-10-14 16:23:17 EDT
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.
Comment 11 Thomas J. Baker 2004-10-15 10:46:52 EDT
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.
Comment 12 Sylvain MEDEOT 2004-10-23 10:19:19 EDT
Got exactly the same problems on a Fedora Core 2. 
Adding the following line

use chroot = no 

in /etc/rsyncd.conf

solved the issue...
Comment 13 Thomas J. Baker 2004-11-12 14:18:40 EST
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.
Comment 14 Jay Fenlason 2005-05-17 14:03:42 EDT
Have you had this problem with any version of rsync shipped in Fedora Core 3 
or later?  Ifnot, can I close this bug? 
Comment 15 Wayne Davison 2005-08-15 18:01:58 EDT
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.
Comment 16 Jay Fenlason 2005-10-24 11:30:23 EDT
No reply in a long time.  Closing. 

Note You need to log in before you can comment on or make changes to this bug.