При обновлении из репозитория subversion с использованием клиента черепахи svn я получаю ошибку, выглядящую так:
Could not read chunk size: An existing connection was forcibly closed by the remote host.
Это не мешает мне обновляться, просто прерывает процесс обновления, поэтому мне нужно повторить обновление несколько раз, прежде чем оно будет завершено.
Что может вызвать такое поведение и как его исправить?
Я получал сообщение "Could not read chunk size" от клиентов на нескольких машинах.
Ключом к выяснению этого была ошибка в журнале ошибок 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, Build 21511 - 32-бит (Subversion 1.6.17), работающий на 32-разрядной версии Windows XP Pro с пакетом обновления 3 (SP3).
Я получил эту ошибку после щелчка правой кнопкой мыши по перетаскиванию подпапки с версией в другую подпапку с версией в моей локальной папке рабочей копии, а затем выбрав 'SVN Copy versioned items (s) здесь (это Команда контекстного меню TortoiseSVN в проводнике Windows при перетаскивании папок). Вложенная папка содержала один ANSI-кодированный текстовый файл, MANIFEST.MF, который, я считаю, я не изменял (моя конфигурация Subversion не включает тип mime для .MF файлов). Я впоследствии передал недавно скопированную подпапку. Позже, в любое время, когда я пытался обновлять локальные папки рабочей папки Subversion на этом компьютере, у меня была ошибка размера блока.
Я решил это, перезапустив мою службу Subversion/Apache (которая сама по себе не помогла и, возможно, не была необходима), затем удаление недавно добавленной вложенной папки из моей локальной папки рабочей копии он уже попал в репо, поэтому я ничего не потерял), и THEN выполняли обновление, которое преуспело без ошибки размера блока и повторно удаляло вложенную папку, которую я только что удалил.
В моем случае я скопировал TWO версии вложенных подпапок таким образом, и я не смог успешно обновить корень моей локальной рабочей копии, пока я не удалил BOTH из этих новых подпапок.
Я предполагаю, что это ошибка на сервере Subversion и/или TortoiseSVN-клиенте, но у меня нет навыков отладки, чтобы сделать это определение. Я расскажу о своих результатах в TortoiseSVN Issue Tracker и посмотрю, где это происходит.
Я только что это случилось со мной, и это не проблема сервера; моя рабочая копия была повреждена (кстати, мне).
Проблема и (некоторые другие) исчезли после отключения клиентского антивируса.
Я использую сервер Ubuntu с subversion 1.7.4 через Apache.
Проверьте журнал ошибок apache, там должна быть зарегистрирована ошибка с номером ошибки. Это число поможет выяснить, почему соединение было отключено.
Если в журнале ошибок нет ничего, проверьте настройки антивирусного сканера/брандмауэра: некоторые из этих инструментов сбросят соединение, если они считают, что перенесенные данные опасны.
Для нас проблема была таймаутом на Apache. Обновление заняло около 15 минут, но через 10 минут Apache закончил время, в результате чего наш сервер 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.
Я получил такое же сообщение об ошибке при обновлении после того, как переименовал папку и зафиксировал ее. Я создал новый рабочий каталог и не получил ошибку. Итак, я просто переместил свои изменения в новый рабочий каталог, зафиксировал и сдул старый каталог.
Итак, эта ошибка, по-видимому, вызвана повреждением моего локального каталога.
Я тоже получаю это. Наш сервер 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).
VisualSVN 2.5.8: Если бы та же ошибка, следующие шаги помогли мне исправить эту ошибку:
На сервере:
На рабочей станции: