При обновлении из репозитория subversion с помощью клиента svn tortoise я получаю сообщение об ошибке:
Could not read chunk size: An existing connection was forcibly closed by the remote host.
Это не мешает мне обновляться, просто прерывает процесс обновления, так что мне приходится повторять обновление несколько раз, прежде чем оно будет завершено.
Чем может быть вызвано такое поведение и как это исправить?
Я получал сообщение «Не удалось прочитать размер фрагмента» от клиентов на нескольких машинах.
Ключом к выяснению этого была эта ошибка в журнале ошибок Apache:
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Provider encountered an error while streaming a REPORT response. [500, #0]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Problem replaying revision [500, #24]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Can't open file '/usr/site/svnrep/impc/db/revs/16122': Too many open files [500, #24]
У процесса Apache, обрабатывающего операцию svn, заканчивались файловые дескрипторы. На моем сервере Ubuntu я исправил это, отредактировав /etc/security/limits.conf и добавив это внизу:
* hard nofile 5000
* soft nofile 5000
Что увеличивает лимит файловых дескрипторов с 1024 до 5000. Затем я вошел в новую оболочку и подтвердил, что лимит увеличился через ulimit -n. Затем перезапустил Apache.
Я только что получил сообщение об ошибке "не удалось прочитать размер фрагмента" И НАШЕЛ РЕШЕНИЕ -- по крайней мере, для одного сценария.
СЕРВЕР: CollabNet Subversion Edge Server 2.0.0-2190.74 (бинарные файлы Subversion 1.6.17-2190.74), работающий на 32-разрядной версии Windows Server 2003.
КЛИЕНТ: TortoiseSVN 1.6.16, сборка 21511 — 32-разрядная версия (Subversion 1.6.17), работающая на 32-разрядной версии Windows XP Pro с пакетом обновления 3 (SP3).
Я получил эту ошибку после перетаскивания правой кнопкой мыши подпапки с версиями в другую подпапку с версиями в папке моей локальной рабочей копии, а затем выбора 'SVN Копировать элементы с версиями здесь' (это контекстное меню TortoiseSVN в Проводнике Windows при перетаскивании папок правой кнопкой мыши). Подпапка содержала один текстовый файл в кодировке ANSI, MANIFEST.MF, который, как мне кажется, я не модифицировал (моя конфигурация Subversion не включает MIME-тип для файлов .MF). Впоследствии я зафиксировал только что скопированную подпапку. Позже, каждый раз, когда я пытался обновить папки локальной рабочей копии Subversion на этом ПК, я получал ошибку размера фрагмента.
Я решил эту проблему, перезапустив мою службу Subversion/Apache (что само по себе не помогло и, возможно, не было необходимо), а затем удалив только что добавленную подпапку из папки моей локальной рабочей копии (она уже добрался до репозитория, так что я ничего не потерял), и ЗАТЕМ выполнил обновление, которое прошло успешно без ошибки размера фрагмента и повторно извлекло подпапку, которую я только что удалил.
В моем случае я таким образом скопировал ДВЕ подпапки с версиями, и я не мог успешно обновить корень моей локальной рабочей папки до тех пор, пока не удалил ОБЕ эти новые подпапки.
Я предполагаю, что это ошибка сервера Subversion и/или клиента TortoiseSVN, но у меня нет навыков отладки, чтобы определить это. Я сообщу о своих выводах в системе отслеживания проблем TortoiseSVN и посмотрю, что из этого получится.
Со мной только что случилось такое, и это была не проблема с сервером; моя рабочая копия была повреждена (кстати, мною).
Проблема и (некоторые другие) исчезли после отключения клиентского антивируса.
Я использую сервер Ubuntu с Subversion 1.7.4 через Apache.
Проверьте журнал ошибок apache, там должна быть ошибка с номером ошибки. Этот номер поможет выяснить, почему соединение было разорвано.
Если в журнале ошибок ничего нет, проверьте настройки антивирусного сканера/брандмауэра: некоторые из этих инструментов разрывают соединение, если посчитают передаваемые данные опасными.
Для нас проблема заключалась в тайм-ауте на Apache. Обновление заняло около 15 минут, но время ожидания Apache истекло через 10 минут, в результате чего наш сервер SVN выдал ошибку, которую вы видите. Окончательным решением было увеличить время ожидания для Apache. Мы используем сервер VisualSVN — подробные инструкции по изменению этой настройки смотрите здесь: http://adventuresindotnet.blogspot.com/2010/09/svn-trouble.html
Я перешел на сервер Ubuntu, и у нас была такая же ошибка — на нескольких клиентских ПК, ОС и клиентских версиях.
Убедившись, что и настройки ограничения файлов, и настройки тайм-аута Apache соответствуют предложенным.
(См. http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/ )
В конце концов я решил проблему, используя пакет apache2-mpm-prefork, а не пакет apache2-mpm-worker.
Я получал такое же сообщение об ошибке при обновлениях после того, как переименовал папку и зафиксировал ее. Я создал новый рабочий каталог и не получил ошибку. Итак, я просто переместил свои изменения в новый рабочий каталог, зафиксировал и удалил старый каталог.
Итак, эта ошибка, похоже, была вызвана повреждением моего локального каталога.
VisualSVN 2.5.8: была та же ошибка, следующие шаги помогли мне исправить эту ошибку:
На сервере:
На рабочей станции:
Я тоже это понимаю. Наш сервер Apache работает на Windows. Мой клиент подключен с высокой скоростью, но с довольно большой задержкой (200 мс). Другая часть головоломки заключается в том, что я использую Windows Vista. Включение автомасштабирования и rss вроде улучшает ситуацию, но не исправляет.
Есть еще одна досадная причина появления этого сообщения об ошибке. Это может быть ваш маршрутизатор или прошивка вашего маршрутизатора.
Недавно я обновил прошивку своего Linksys WRT110 с версии 1.0.02 до 1.0.07, и после этого subversion больше не могла добавлять новые файлы в репозиторий. Он мог только обновлять существующие файлы. Откат на 1.0.02 решил проблему.
Источники:
По сути, каждый раз, когда соединение резко обрывается, вы получите эту ошибку. Как многие из вас заявили, это может быть ошибка конфигурации Apache. Это также может быть связано с медленным сервером или перегруженным соединением, а может быть с дешевым роутером, как было в моем случае.
Это явно имеет много причин, но для меня это было исправлено путем перезапуска моего сервера SVN (VisualSVNServer 2.5.1). Это часто происходит при выполнении полной проверки репо на только что загруженном дампе.
Для нас обходной путь заключался в понижении версии клиента SVN с версии 1.8 до версии 1.7 (клиент командной строки, поставляемый вместе с TortoiseSVN).
