Rsync внезапно висит бесконечно во время трансферов

В течение последних нескольких лет я использовал однострочную rsync для резервного копирования важных папок на моем рабочем столе Mac Mini (OSX 10,9, 2,5 ГГц i5, 4 ГБ ОЗУ) на коробку FreeNAS (0.7.2 Sabanda, версия 5266, Pentium). D 2,66 ГГц, 822 МБ ОЗУ [сообщается системой, я думаю, что там 1 ГБ]]. Я запускаю демон rsync на коробке FreeNAS. В последнее время эти переводы зависали до бесконечности. Я сделал обычный Google-фу и не могу определить источник проблемы или решения.

Однострочник это:

rsync -rvOlt --exclude '.DS_Store'                                  \
      --exclude '.com.apple.timemachine.supported'                  \
      --delete /Volumes/Storage/Music/Albums/ 192.168.1.100::albums

Я попытался включить -vvv и --progress, но я не могу различить, что зависает, а что нет. Черт возьми, если я повторюсь, один и тот же файл может зависнуть в другой точке во время передачи или нет вообще. -n прогон (-n) также не всегда успешен. Единственный "успех", который у меня был, - реализация тайм-аута (--timeout=10) и --timeout=10 команды снова и снова. В конце концов, я ползу вперед, но без гарантии успеха и в темпе, который неприемлем. Я достиг точки, когда у меня есть один файл, который я не могу пройти.

Mac Mini подключен к моему маршрутизатору через 5 ГГц. Блок FreeNAS подключен к тому же маршрутизатору через порт 100 Мбит. Когда передача действительно происходит, rsync --progress сообщает о 2,5-4 МБ/с. Согласно --progress, зависание - это буквально просто - насколько я могу судить, передача данных не происходит.

Мне нужна помощь как с диагностикой, так и с решением.

Ответ 1

Я снова и снова сталкивался с одним и тем же, и, похоже, он помогает, если вы выкинете опцию -v (что раздражает, если вам нужен этот вывод).

Ответ 2

Это случилось со мной, когда на удаленном устройстве закончилось свободное пространство. Ошибка не будет отображаться при использовании опции --verbose; выключение этого выхода привело к выходу какого-либо выхода STDERR, в котором объяснялось, что удаленное устройство было вне места. Когда я освободил некоторое пространство, я снова смог запустить rsync с помощью --verbose, и все прошло хорошо.

Ответ 3

У меня была такая же проблема. Удаление -v не помогло мне. Мой прецедент немного отличается тем, что я перехожу из источника (EXT4) в ExFAT. Проблема для меня заключалась в том, что rsync пытался сохранить файлы устройств и разрешения, которые ExFAT не поддерживает. Я использовал переключатели -hrltDvaP. Переключатели -D и -a, казалось, были моей проблемой. Переключатель -a преобразуется в -rlptgoD (no -H,-A,-X). Переключатели -p, -g и -o, по-видимому, были моей основной причиной, поскольку rsync был включен в один или все из них во время выполнения. Удаление -a и явное указание переключателей -Prltvc работает для меня.

bkupcmd="nice -n$nicelevel /usr/bin/rsync -Prltvc --exclude-from=/var/tmp/ignorelist "

Ответ 4

Я использую openSUSE 13.2 Linux, rsync версию 3.1.1-2.4.1.x86_64, и у меня возникли аналогичные проблемы, выполняющие rsync между моим ноутбуком и внешним жестким диском, при этом целевое устройство окончательно имеет достаточно свободного места.

Я думал, что у меня есть вариант исключения, но после 10 минут он снова висит: strace сказал: выберите (5, [], [4], [], {60, 0}) = 0 (Тайм-аут)

И с помощью "iotop", который я советовал, убедитесь, что процессы rsync больше не сделали значительного дискового ввода-вывода.

Ни удаление параметра -v, ни ограничение полосы пропускания с использованием --bwlimit устраняли проблему.

Ответ 5

Просто была похожая проблема при rsync с жесткого диска на USB-накопитель FAT32. rsync заморозился уже менее чем за секунду в моем случае и не реагировал вообще после этого... оставил его с помощью CTRL + C.

Выяснилось, что проблема заключалась в комбинации использования жестких ссылок на жестком диске и наличия файловой системы FAT32 на USB-накопителе, которая не поддерживает жесткие ссылки.

Форматирование USB-накопителя с помощью ext4 решило проблему для меня.

Ответ 6

У меня была та же проблема, и это было потому, что у меня не хватало памяти во время rsync. Создан файл подкачки и проблема решена.

Ответ 7

В моей ситуации rsync фактически не работал.

У меня есть обычные резервные копии сервера, которые передают большие файлы через 500GB+ и имеют --append-verify или --checkusm через параметры ssh.

Что я обнаружил после анализа, так это то, что как только клиентская сторона завершает проверку файлов, начинаются проверки на стороне сервера. Это означает, что пока сервер делает это, он проверяет, что клиентская сторона будет зависать и зависать - запустите htop на сервере, чтобы rsync работал.

Это, вероятно, не проблема, если rsync запускается в режиме deamon на сервере и использует протокол rsync вместо ssh для передачи.

Что касается примечания, то это очень долгое ожидание будет вызывать тайм-аут SSH и rsync: connection unexpectedly closed (254 bytes received so far) [sender] сообщение об ошибке rsync: connection unexpectedly closed (254 bytes received so far) [sender], решение - добавить ClientAliveInterval 120 и ClientAliveCountMax 720 в /etc/ssh/sshd_config.

Ответ 8

Скорее всего, не ваша "проблема", но я наткнулся на этот вопрос, когда изучал подобное поведение:

Я наблюдаю "зависание", когда на целевом сайте слишком много загрузок io. например. на одном из моих серверов малого бизнеса, когда кто-то переписывает свою учетную запись IMAP и загружает большие партии данных и запускается задание резервного копирования, которое записывает его данные.

В этой ситуации я замечаю резкое снижение производительности для rsync. Заметно, что значение высокой загрузки в top на целевой машине, даже если CPU и Mem являются точными.

Ожидание завершения процесса помогло каждый раз или снова и снова прерывать rsync.

Ответ 9

Это также происходит, когда пользователь на целевой машине не имеет прав на запись в целевую папку.
Вы можете попробовать дать разрешение на запись в другую целевую папку:

sudo chmod -R o+w /path/to/target-folder

Ответ 10

Возникла проблема с зависанием rsync в Ubuntu 16. Ни один из приведенных выше вариантов не помог. Проблема была в исходном диске (внешний SSD), который внезапно стал неисправным. Я попробовал несколько проверок диска, но все они застряли. Закончилась перезагрузка системы, и диск внезапно снова стал доступен.