Синхронизация Unison между Windows/Linux зависает случайным образом во время передачи
Мы регулярно разворачиваем процессоры интерактивных киосков на удаленных физических сайтах, и я разработал приложение для обновления контента, которое выполняет ночную синхронизацию мультимедийных ресурсов между каждым киоском (Windows 7 Pro) и размещенной CMS (виртуализированный сервер Ubuntu, работающий на linode.com)., Средство обновления контента создано в C#/.NET и порождает дочерний процесс Unison с помощью Process.Start(). Unison настроен для подключения к удаленному серверу через SSH с использованием закрытого ключа.
Проблема, которую мы затрагиваем, заключается в том, что при порождении в качестве дочернего процесса из ContentUpdater.exe Unison часто просто прекращает связь с удаленным сервером во время передачи и зависает на неопределенное время. Простого воспроизведения нет - иногда работает, чаще всего зависает. Кажется, он более хрупок при больших обновлениях (400 МБ +), но это скорее предположение, чем что-либо еще. Когда он зависает, процесс Unison на клиенте (Windows 7) по-прежнему показывает 25% загрузки ЦП, и сервер также показывает, что процесс unison также работает - сетевой активности просто нет. Я знаю, что он соединяется, потому что он всегда запускает процесс и проходит через часть передачи, но он никогда не зависает в одном и том же месте дважды. Я использую двоичную сборку Windows Unison-2.40.63.exe и ту же версию unison на удаленном сервере.
Командная строка Unison в Windows выглядит следующим образом:
Unison-2.40.63.exe -contactquietly -silent -batch -sshcmd "C:\KioskManagement\Apps\ssh2plink.bat" -sshargs "-p 22 -i C:\cygwin\home\someuser\.ssh\contentupdater-rsync-key.ppk" -ignore "Path {innovations,todaytomorrow,scale,mooreslaw,brilliantminds,askafab}" ssh://cmsuser@server//home/cms/base-preview/webapps/ROOT/applications C:\kioskdir\temp\applications -force ssh://cmsuser@server//home/cms/base-preview/webapps/ROOT/applications
Для записи я изначально создал средство обновления контента для использования rsync (через cygwin в Windows), но столкнулся с теми же проблемами. Чтобы проверить, не является ли проблема с передачей ssh, я попытался использовать rsync в режиме сервера (rsyncd), но зависание продолжало поднимать голову.
На данный момент я полностью озадачен. Эта проблема повторяется и на других серверах, так что я думаю, что это связано с Windows. Я также склонен полагать, что проблема возникает только при вызове Unison/rsync из Process.Start () внутри другого процесса (ОБНОВЛЕНИЕ: я только что получил его для воспроизведения при запуске из командной строки) - похоже, это не так ошибка при запуске непосредственно из командной строки. Unison/rsync также никогда не выдает ошибку, поэтому нет файлов журналов для проверки (если кто-то не знает какой-либо трассировки на стороне сервера или файла журнала на удаленном сервере, я могу проверить - полное раскрытие: я фанат FreeBSD и знаю, мало что про убунту под капотом).
Заранее спасибо за любые идеи / решения / решения!
Лучший
3 ответа
У меня была эта проблема. Мне потребовалось несколько дней, чтобы решить это. Закончилось тем, что добавление -halfduplex решило мою проблему.
Как указано в документации:
полудуплекс Когда этот флаг установлен в true, сетевая связь Unison вынуждена быть полудуплексной (клиент и сервер никогда не передают данные одновременно). Если у вас возникли проблемы с сетевым подключением, это может помочь. Связь всегда полудуплексна при синхронизации с машиной Windows из-за ограничения текущей реализации Unison, что может привести к тупику.
В моем случае я синхронизировался между Windows/OSX.
Я подтверждаю, что настройка "halfduplex = true" решила мои проблемы с зависанием. В качестве центральной точки синхронизации у меня были настроены Win7 и OSX "клиенты" и сервер Linux. Все клиенты синхронизируются с сервером.
Проблемы начались, когда я представил клиента Mac на картинке, с тех пор обновления начали происходить в обоих направлениях. Установка "halfduplex = true" в профиле Unison решила мою проблему.
Как ни странно, Unison прекрасно синхронизировал гораздо меньший каталог между двумя клиентами Win7 и сервером Linux, но в этом случае файлы намного меньше.
Просто звонит; У меня та же проблема с использованием rsync/cygwin между двумя компьютерами Windows 7. В старых дискуссиях в сети предполагалось, что проблема затрагивает только ssh-соединения, но метод rsync daemon для меня не работает. Есть сообщения, притворяющиеся о том, что нужно перекомпилировать rsync из источника, отключив HAVE_SOCKETPAIR, что, как говорят, заставляет rsync/ssh работать. Я не удосужился попробовать это.