У меня есть несколько клиентов 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 но удалил их, прочитав на другом форуме, что кто-то решил некоторые проблемы с задержкой, удалив эти параметры. Я также пробовал эту команду в форме сценария оболочки, думая, что, возможно, проблема заключалась в том, что мой клиент rsync пытался повторно использовать просроченное соединение ssh. С этой целью он, по-видимому, случайно не работает при использовании rsh или ssh. Периодически он выходит из строя, делаю я или нет --del или --delete, --compress или не, --rsync-path или не.
Я не могу заставить команду выйти из строя из командной строки, но когда она выполняется каждую минуту, она дает сбой 5–15 раз в час, в зависимости от каталога, который синхронизируется с rsync. Разрешения и права владения кажутся правильными, и я не полагаюсь на какие-либо переменные среды, которые могут вызвать сбой cron. Все соответствующие программные пакеты (bash, rsync, ssh, Linux) обновлены, все ключевые порты открыты, и все клиенты не выходят из строя одновременно, что позволяет предположить, что это не проблема на стороне сервера.
tldr: rsync иногда дает сбой при запуске в качестве задачи cron, что исключает большинство проблем RTFM, но проблема сохраняется.
Обновление: 20.09.10: обновлен EC2 AMI как на клиенте, так и на сервере, и проведен тест с тремя модулями с двумя клиентами, загружающимися с одного сервера в течение 24 часов. По завершении теста в журналах не было ошибок, поэтому я начал заменять другие экземпляры обновленными экземплярами 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]
Разве нецелесообразно одновременно подключать к серверу rsync 35 клиентов? Возможно, это проблема с загрузкой?
Спасибо Изидору Джеребичу, разместившему решение в списке рассылки rsync:
это может быть проблема с максимальным количеством одновременных ssh-соединений или запросов на соединение. У демона Ssh есть два параметра конфигурации, в которых вы можете определить максимальное количество клиентов, которые могут подключаться одновременно. Это число по умолчанию не очень велико, так что вы, вероятно, столкнулись с этим пределом.
MaxSessions
Задает максимальное количество открытых сеансов, разрешенное для одного сетевого подключения. По умолчанию - 10.
MaxStartups
Задает максимальное количество одновременных неаутентифицированных подключений к демону SSH. Дополнительные подключения будут сброшены до тех пор, пока аутентификация не будет успешной или не истечет время LoginGraceTime для подключения. По умолчанию - 10.
После повышения этих значений все работает нормально. Чтобы не скрывать того факта, что это была проблема RTFM, но ни MaxStartups, ни MaxSessions не определены на странице руководства ssh. И хотя MaxStartups по крайней мере появляется в файле sshd_config, MaxSessions, похоже, отображается только в журнале изменений OpenSSH (http://www.openssh.org/txt/release-5.1).