我有一些rsync客户端试图连接到一个rsync服务器的例行公事，他们间歇性地失败与几个错误消息之一。
或者：
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7] 要么：
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(601) [Receiver=3.0.7]
我使用的rsync命令的当前版本是：
rsync --rsync-path="/usr/bin/rsync" --stats --compress --times --links \ --log-file=/home/ubuntu/rsynclog.txt --exclude thatfile --recursive \ xxx.xx.xxx.xx:/home/ubuntu/utility_scripts/ /home/ubuntu/utility_scripts &
我以前有过 – --progress和 – --progress但在阅读另一个论坛后删除他们，有人通过删除这些选项解决了一些延迟问题。 我也以shell脚本的forms尝试了这个命令，可能是因为我的rsync客户端试图重用一个过期的ssh连接。 为此，无论是使用rsh还是ssh，它都会随机失败。 它是否会定期失败--del或--delete ， – 是否--compress ， – --rsync-path或不。
我无法从命令行获得命令失败，但是当它每分钟运行一次时，它每小时失败5-15次，具体取决于rsync的目录。 权限和所有权看起来都是正确的，我不依赖任何会导致cron失败的环境variables。 所有相关的软件包（bash，rsync，ssh，Linux）都是最新的，所有的关键端口是开放的，并且所有的客户端不会同时失败，这表明这不是服务器端的问题。
tldr：rsync有时会在作为cron任务运行时失败，排除了大多数RTFM问题，但问题仍然存在。
更新：9/20/10：更新了客户端和服务器上的EC2 AMI，并运行了3台testing，其中2台客户端在24小时内从1台服务器下载。 testing完成后，日志没有错误，所以我开始用更新的AMI实例replace其他实例。 经过35-40个客户的周末之后，我再次login了以下日志：
2010/09/20 16:27:01 [18581] rsync error: error in rsync protocol data stream (code 12) at io.c(601) [Receiver=3.0.7] 2010/09/20 16:30:01 [18627] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7] 2010/09/20 16:36:01 [18739] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7] 2010/09/20 16:40:02 [18810] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7] 2010/09/20 16:50:01 [18972] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7] 2010/09/20 17:00:01 [19139] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7] 2010/09/20 17:10:01 [19328] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]
有35个客户端同时连接到rsync服务器是不合理的吗？ 这可能是一个负载问题？
感谢将解决scheme发布到rsync邮件列表的Izidor Jerebic：
这可能是最大数量的并发ssh连接或连接请求的问题。 SSH守护进程有两个configuration设置，您可以在其中定义可以同时连接的最大客户端数量。 这个数字默认不是很高，所以你可能会碰到这个限制。
MAXSESSIONS
指定每个networking连接允许的最大打开会话数。 默认值是10。
MaxStartups
指定与SSH守护进程并发的未经身份validation的连接的最大数量。 其他连接将被丢弃，直到身份validation成功或LoginGraceTime到期为连接。 默认值是10。
增加这些值后，一切都运行得很好。 不要隐瞒这是一个RTFM问题，但是在ssh手册页中没有定义MaxStartups或MaxSessions。 尽pipeMaxStartups至less出现在sshd_config文件中，但MaxSessions似乎只出现在OpenSSH更改日志（ http://www.openssh.org/txt/release-5.1 ）中。