Bug 59091

Summary: rsync with max connections set only allows a single connection
Product: [Retired] Red Hat Linux Reporter: Need Real Name <peters>
Component: rsyncAssignee: Bill Nottingham <notting>
Status: CLOSED ERRATA QA Contact: Aaron Brown <abrown>
Severity: high Docs Contact:
Priority: medium    
Version: 6.2CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-02-01 20:03:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to turn off -D_FILE_OFFSET_BITS=64 compile time option
none
Strace output of failing rsync and working rsync
none
Notes
none
rsync-2.4.6-0.6es1 spec file none

Description Need Real Name 2002-01-30 19:54:08 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.19-6.2.1 i686)

Description of problem:
After installing rsync-2.4.6-0.6 we noticed that anonymous rsync would allow the
first connection, but then refuse subsequent connections, providing an error
message of

@ERROR: max connections (10) reached - try again later

even though there was only one rsync process running.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. create /etc/rsyncd.conf and set "max connections = 10"
2. start an anonymous rsync session  rsync rsync://server/module/file .
3. start another concurrent anonymous rsync connection and you'll see the error
message
4. run ps auxww | grep rsync on the server and you'll see there is only one
rsync process running
	

Actual Results:  The second (and sunsequent) anonymous rsync sessions were all
refused access and presented with the error message

@ERROR: max connections (10) reached - try again later

Expected Results:  Each anonymous rsync session (up to an including the 10th)
should have succeeded.

Additional info:

uname -a
	Linux manuel 2.2.14-5.0.14smp #1 SMP Sun Mar 26 13:03:52 PST 2000 i686 unknown

rpm -q rsync
	rsync-2.4.6-0.6

rpm -q glibc
	glibc-2.1.2-11
Comment 1 Need Real Name 2002-01-30 19:57:07 UTC 
Created attachment 44017 [details]
Patch to turn off -D_FILE_OFFSET_BITS=64 compile time option
Comment 2 Need Real Name 2002-01-30 20:03:27 UTC 
Created attachment 44018 [details]
Strace output of failing rsync and working rsync
Comment 3 Need Real Name 2002-01-30 20:05:44 UTC 
Created attachment 44019 [details]
Notes
Comment 4 Need Real Name 2002-02-01 20:01:37 UTC 
My patch was too aggressive. it broke remote file size negotiation.

IE If you already have a partially complete file on the target servercand you
attempt to syncroonise it with the master copy, you'd see the following error
messages and you'd copy much more than you'd need:

	Warning: unexpected read size of 0 in map_ptr
	Warning: unexpected read size of 0 in map_ptr
	308634655 (110%)

I have backed out my last patch and instead I'm rebuilding util.o without the

	-D_FILE_OFFSET_BITS=64

option.

The only change from my version and yours is the spec file. I'll attach it to
this bug report.
Comment 5 Need Real Name 2002-02-01 20:03:09 UTC 
Created attachment 44277 [details]
rsync-2.4.6-0.6es1 spec file
Comment 6 Bill Nottingham 2002-02-04 20:47:58 UTC 
This should be fixed with the new errata; it's a different issue.