Description of problem: Original report can be found here: https://www.redhat.com/archives/fedora-olpc-list/2008-August/msg00101.html I've reproduced this with a stock fedora, not including xs-rsync or other OLPC packages. running rsync against localhost gives: $ rsync rsync://localhost/ rsync: read error: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(794) [receiver=3.0.3] While in /var/log/messages the following appears: Aug 30 19:20:57 localhost xinetd[29293]: START: rsync pid=29348 from=::ffff:127.0.0.1 Aug 30 19:20:57 localhost rsyncd[29348]: rsync: getpeername on fd0 failed: Invalid argument (22) Aug 30 19:20:57 localhost rsyncd[29348]: rsync error: error in socket IO (code 10) at clientname.c(168) [receiver=3.0.3] Aug 30 19:20:57 localhost xinetd[29293]: EXIT: rsync status=10 pid=29348 duration=0(sec) This happens when rsync is run under fakechroot, but not when it is run normally. Version-Release number of selected component (if applicable): fakechroot-2.8-13.fc9.i386 rsync-3.0.3-0.fc9.i386 xinetd-2.3.14-20.fc9.i386 How reproducible: always Steps to Reproduce: 1. Set up rsync like so: /etc/xinetd.d/rsync: http://rnorwood.fedorapeople.org/rsync /etc/rsyncd.conf: http://rnorwood.fedorapeople.org/rsyncd.conf 2. Verify that rsync works fine: $ sudo /sbin/service xinetd restart Stopping xinetd: [ OK ] Starting xinetd: [ OK ] $ rsync rsync://localhost/ share share drive 3. Change /etc/xinetd.d/rsync so that rsync runs under fakechroot: http://rnorwood.fedorapeople.org/rsync-fakechroot Actual results: $ rsync rsync://localhost/ rsync: read error: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(794) [receiver=3.0.3] Expected results: $ rsync rsync://localhost/ share share drive Additional info: I notice in rsync's configure.sh there is a stanza that seems to be changing the args to getpeername based upon the platform. Maybe the args from fakechroot do not match. Also, to test this, I completely removed the getpeername function from rsync and rebuilt it, and the problem went away. The patch I used: http://rnorwood.fedorapeople.org/robin-fakechroot.patch
Thanks for the debugging! I think the next steps are to reenable the getpeername wrapper in fakechroot and see which part of the code makes it bail out. But I think I already see the bug, newnamelen is never initialized. It should look like char *fakechroot_path, *fakechroot_ptr, fakechroot_buf[FAKECHROOT_MAXPATH]; if (next_getpeername == NULL) fakechroot_init(); - memset(&newname, 0, sizeof(struct sockaddr_un)); + newnamelen = sizeof(struct sockaddr_un); + memset(&newname, 0, newnamelen); status = next_getpeername(s, (struct sockaddr *)&newname, &newnamelen); if (status != 0) { return status; } Can you try the above and see if it fixes it? Thanks!
yes, your patch fixes the issue for me, thanks! Also, getsockname() follows the same pattern, and looks like it could use a similar patch as well.
Thanks for testing and reporting! I'll wait a day or two for upstream's comments and will commit the fixes. Currently the updates are stalled anyway. :(
ping? Just checking to see if this fix will be in F10.
---------- Forwarded message ---------- From: Piotr Roszatycki <dexter> Date: Fri, Sep 12, 2008 at 8:20 AM Subject: Re: [Server-devel] RFH - xs-rsync on F9 fails with an odd error To: Martin Langhoff <martin.langhoff> Thanks for patch. I think I'll apply it to new fakechroot's release. ---------- End Forwarded message ------
*bump* :-)
fakechroot-2.8-15.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/fakechroot-2.8-15.fc9
fakechroot-2.8-15.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/fakechroot-2.8-15.fc8
fakechroot-2.8-15.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
fakechroot-2.8-15.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Just a quick - THANKS!