Как дебагировать сокеты не привлекая внимания

[coolwolf0]

Я тут уже почти третью неделю кряду пытаюсь разгадать секрет, почему зависает удалённый клиент при ЛЮБОМ подключении к некоему множеству линуксовых хостов.
Перепробованы аж два вида соединений - по RPyC и SSH. В обоих случаях, если контролируемый удалённо процесс бежит меньше часа, то клиентская сторона получает отчётливый сигнал о завершении. А вот стоит перейти границу часового ожидания, и всё - процесс на стороне сервера успешно отрабатывает, а клиент этого не видит и ждёт у сокета погоды (пока не помирает через собственный тайм-аут).

Дебагировать такую пакость при помощи дебаггера - штука опасная в том плане, что наблюдатель привносит в наблюдаемую систему очевидное крушение сценария: вместо обслуживания сокета, сервис будет ужасно долго чикаться с интерактивным дебаггером. Поэтому ВПС пошёл другим путём - подключил в "подозрительный" код трейсер pysnooper.
 (благо у RPyC серверная часть тоже на Пайтоне написана). Получилось прикольно (жалко, что не помогло - лажа оказалась на уровне сокета, а там никакой трейсер уже нифигашечки не видит). Тем не менее, если будете такие вещи дебагировать - попробуйте. Это реально удобная штука, хотя бы для вынесения вердикта "тут всё в порядке - проблемы где-то глубже", ибо исполняемый код можно натурально просмотреть глазами.

Кстати, просто анализируя код, мой коллега нашёл баг в RPyC версии 4.1.4 - если у кого тормозит при передаче данных, откатитесь на пару версий назад.

Comments

[sashaandaigul.livejournal.com]

Я strace юзаю в таких случаях. Если хорошо настроить фильтр, то можно довольно подробно видеть, что именно пихается клиентом в сокет, и что он получает в ответ, если обмен идет ascii-строками.

[coolwolf0]

Увы, strace выуживает только передаваемую информацию, а мне надо было понять, кто поймал exception или обошёл обработку некоего цикла. А обмена информацией как такового тут нет - только опрос состояния на самом низком уровне.