rsync --server and "max connections"

[Jeremy Lepore]

Thanks Wanye for your reply. We were actually considering a queue
approach.

As far as "rsync --server" is concerned, is there a recommended limit on
the number of parallel sessions per target node?

The purpose my questions is to resolve what could possibly be causing
unexpected hangs with rsync. From time to time, according to truss, rsync
falls asleep in the middle of _select/kwriting to its remsh process on the
target node:

< truss output >
...
kwrite(4, "040404040404040404040404".., 16392)  = 4096
_select(5, 0x00000000, 0x2FF18018, 0x00000000, 0x2FF18010) (sleeping...)
_select(5, 0x00000000, 0x2FF18018, 0x00000000, 0x2FF18010) = 0
_select(5, 0x00000000, 0x2FF18018, 0x00000000, 0x2FF18010) (sleeping...)

< /truss output>

We _were_ considering a hidden connection limitation ( where a limit is
greeted with a stall instead of a message ) as a cause for this problem.

There may be as much as five other "rsync --server" sessions at a given
point in time on the target node. Each session has one rshd process, one
"rsync --server" child, and one "rsync --server" grandchild.

Flags typically used are "-ulogpr".

Any thoughts are greatly appreciated.

Jeremy 

On Wed, 13 Jul 2005, Wayne Davison wrote:

> On Tue, Jul 12, 2005 at 10:06:09PM -0400, Jeremy Lepore wrote:
> > Is there also [a "max connections"] when rsync --server (on the target
> > node) is us used (in the absence of a rsyncd.conf file) ? 
> 
> There is nothing like that built-in to rsync.  You could, however,
> create a wrapper script that would do some kind of locking and refuse to
> run rsync if there were too many concurrent rsync invocations (put the
> wrapper in place of the normal rsync, and have it call the relocated
> rsync if it gets a lock).  As long as the wrapper outputs an error
> message on stderr (not stdout) when the locking failed, the user would
> see the reason why their rsync command failed.
> 
> ..wayne..
>