☰

通过 cron 使用 Ubuntu 10.04 进行 ssh 上的间歇性 rsync 错误：无法解释的协议数据流

tag-icon • tag-icon ubuntu ssh cron rsync
通过 cron 使用 Ubuntu 10.04 进行 ssh 上的间歇性 rsync 错误：无法解释的协议数据流

我有许多 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 &

我之前有和--verbose，--progress但在另一个论坛上看到有人通过删除这些选项解决了一些延迟问题后，我删除了它们。我也尝试过以 shell 脚本的形式执行此命令，认为问题可能是我的 rsync 客户端试图重用已过期的 ssh 连接。为此，无论使用 rsh 还是 ssh，它似乎都会随机失败。无论我是否执行--del或--delete，--compress或不执行，它都会定期失败--rsync-path。

我无法从命令行让命令失败，但当它每分钟运行时，每小时会失败 5-15 次，具体取决于正在 rsync 的目录。权限和所有权似乎都是正确的，而且我没有依赖任何会导致 cron 失败的环境变量。所有相关软件包（bash、rsync、ssh、Linux）都是最新的，所有关键端口都已打开，并且所有客户端不会同时失败，这表明这不是服务器端问题。

tldr：rsync 作为 cron 任务运行时有时会失败，已经排除了大多数 RTFM 问题，但问题仍然存在。

更新：2010 年 9 月 20 日：更新了客户端和服务器上的 EC2 AMI，并运行了 3 盒测试，2 个客户端在 24 小时内从 1 个服务器下载。测试完成后，日志没有任何错误，因此我开始用更新的 AMI 实例替换其他实例。在运行了 35-40 个客户端一个周末后，我的日志再次充满了以下内容：

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 服务器是否不合理？这可能是负载问题吗？

答案1

感谢 Izidor Jerebic 将解决方案发布到 rsync 邮件列表：

这可能是 ssh 最大并发连接数或连接请求数的问题。ssh 守护进程有两个配置设置，您可以在其中定义可以同时连接的最大客户端数。默认情况下，这个数字不是很高，因此您可能会遇到该限制。

最大会话数

指定每个网络连接允许打开的最大会话数。 默认值为 10。

最大创业公司

指定与 SSH 守护程序的最大并发未经身份验证的连接数。额外的连接将被丢弃，直到身份验证成功或连接的 LoginGraceTime 到期。 默认值为 10。

增加这些值后，一切都运行良好。不掩盖这是一个 RTFM 问题的事实，但 ssh 手册页中没有定义 MaxStartups 或 MaxSessions。虽然 MaxStartups 至少出现在 sshd_config 文件中，但 MaxSessions 似乎只出现在 OpenSSH 更改日志中 (http://www.openssh.org/txt/release-5.1）。

相关内容