rsync не синхронизирует файлы

Я столкнулся со странной проблемой. Я обычно использую rsync синхронизировать файлы между серверами, и теперь эта утилита ведет себя странным образом.

Во-первых, вот команда, которую я использую:

server1# rsync -av -e ssh ./server1_dir/ root@192.168.1.1:/server2_dir/

Он запускает процесс синхронизации, как и должно быть, но файл не синхронизируется, только каталоги. Не все каталоги на самом деле, как rsync процесс зависает в течение длительного времени, что приводит к ошибке тайм-аута.

Если я убью процесс и сделаю еще одну попытку, он вообще не запустится. Единственное сообщение, которое я вижу:

sending incremental file list

Первая мысль была - межсетевой экран. Но на обоих серверах он не установлен. Я даже пытался вручную собрать последние rsync Версия без успеха, хотя.

Может ли кто-нибудь помочь мне в этой проблеме? Большое спасибо.

Обновить. выводить данные на сервер1

root@server1 [~]# ps auxf|grep [r]sync
root     13958  0.0  0.0  70676  1232 pts/0    S+   23:29   0:00  |       \_ rsync -avv -e ssh directory1 root@192.168.1.1:/home
root     13959  0.0  0.2  58436  3256 pts/0    S+   23:29   0:00  |           \_ ssh -l root 192.168.1.1 rsync --server -vvlogDtpre.isf . /root

root@server1 [~]# strace -p 13959
Process 13959 attached - interrupt to quit
select(7, [3 4], [], NULL, NULL

2 ответа

Решение

Наконец, проблема была решена. Трудно поверить, но это был неверный MTU, установленный на главном сетевом интерфейсе. После изменения MTU на 1460 процесс синхронизации был запущен и завершен немедленно. Спасибо всем за ответы.

Я столкнулся с теми же симптомами в последнее время. Обе стороны показали, что они находятся в select(), ожидая другую сторону. Затем я заметил, что на стороне сервера была большая очередь отправки в netstat, поэтому я начал искать решения сетевого уровня. Я попытался уменьшить MTU, как указано выше, но это не имело значения. Затем я отключил SACK с обеих сторон, и rsync снова начал работать:

echo 0 > /proc/sys/net/ipv4/tcp_sack

Существует некоторое обсуждение ошибок Cisco с выборочной рандомизацией ack и порядкового номера, что, по крайней мере, является вероятной причиной для изменения ситуации.

Другие вопросы по тегам