| 1 |
Hi!
|
| 2 |
|
| 3 |
On Wed, Jun 13, 2007 at 01:54:58PM +0400, foringer@×××××.com wrote:
|
| 4 |
> Какой либо закономерности в процессе зависания - не обнаружено. |
| 5 |
|
| 6 |
У меня было подобное. Правда, ADSL-модемов в цепочке небыло - я работал
|
| 7 |
тогда через выделенку на обычном 33.6 модеме. Коннектился от себя к
|
| 8 |
удалённому серверу. И, периодически, ssh вот так подвисала. tcpdump ничего
|
| 9 |
левого не показывал. Закономерность в результате долгих мучений выявлена
|
| 10 |
была частично: очень часто подвисание происходило в момент вывода большого
|
| 11 |
объёма информации и очень быстро. Например, если сделать cat большому
|
| 12 |
(экранов на 10-20 текста) файлу. Но изредка вроде ничего большого не
|
| 13 |
выводилось, а всё-равно висла, собака.
|
| 14 |
|
| 15 |
Вылечилась проблема сменой провайдера. :D
|
| 16 |
|
| 17 |
Так что, скорее всего, это действительно баг в iptables -m state.
|
| 18 |
|
| 19 |
|
| 20 |
P.S. Более того, чуть позже я наступил на похожую граблю. Два удалённых
|
| 21 |
сервера между собой интенсивно общались - с обоих сторон мои Perl-скрипты,
|
| 22 |
использующие свой RPC-протокол. И, в какой-то момент, пакеты просто
|
| 23 |
переставали ходить, и соединение "подвисало" в середине получения ответа
|
| 24 |
(довольно объёмного, надо заметить) от RPC-функции. После некоторых мучений,
|
| 25 |
в рамках поиска проблемы методом половинного деления, был отключен файрвол,
|
| 26 |
и всё заработало. Метод половинного деления по правилам файрвола выявил,
|
| 27 |
что проблема была в connection tracking, т.е. как раз в модуле state.
|
| 28 |
|
| 29 |
К сожалению, поскольку это production сервера, то играться с ними,
|
| 30 |
выявлять баг и писать багрепорт в iptables возможности у меня небыло.
|
| 31 |
Просто перенастроил файрвол без использования connection tracking, и всё.
|
| 32 |
:(
|
| 33 |
|
| 34 |
--
|
| 35 |
WBR, Alex. |
Archives