Как поймать вредителя или почему ломается curl?

Question

[Вова]

Всем привет.
Помогите не сойти с ума ;)

Есть сервер. На сервере сборка (винда, студия и всё такое). В процессе сборки запускается нинзя, который запускает питон, который запускает curl, который отправляет файлик на другой сервер.
Раз в неделю эта замечательная конструкция встаёт раком и curl начинает стабильно возвращать код 55: типа "не могу отправить файл на [другой] сервер".
Если пойти по RDP и позвать curl из консольки, то всё работает.

Эффект воcпроизводится стабильно и лечится... перезагрузкой сервера. Или EMET-а. Или касперского.
Хотя в логах у последнего всё чисто.
Визуально, curl успевает отправить несколько МБ на [другой] сервер, после чего залипает минут на 5.
Видимо, после этого у [другого] сервера срабатывает таймаут, и curl честно пишет "ну не шмогла я".

Есть идеи, что может помешать curl-у дочитать файл с диска?
Точно воспроизвести что-то типа "отключил каспера, всё заработало" не получается :(

Как это вообще диагностировать?

Comments

[nirvimel]

Точно воспроизвести что-то типа "отключил каспера, всё заработало" не получается :(

Почему не удается?

Как на счет того, чтобы отключить его полностью, перезагрузить машину (чтобы гад даже не поднимался во время загрузки) и протестировать скрипт.

[Вова]

nirvimel: Потому что он может нормально работать неделями с включенным каспером и еметом. И ломается неожиданно. Нет очевидной причины вида "включил - сломалось". Есть только "наблюдения" вида "выключил - заработало".

[nirvimel]

Вова: Другими словами: при включении Каспера появляется вероятность возникновения проблемы.
Думаю, в эту сторону стоит копать...

[Вова]

nirvimel: Ага. Только доказать я этого не могу :)
И отключить на месяц каспера, чтобы понять, что всё ок, тоже не могу.

Answer 1

[younghacker]

Я бы собирал диагностику сети.
Перед curl или после того как он вернул ошибку запускаете несколько программ которые записывают информацию в лог.
1) пинг себя, гейтвея, гуглднс и целевого хоста по IP. (в зависимости от сетей размещения источника и цели)
2) трейсроут до целевого хоста без лукапа имён
3) переменные окружения (кто я) списки процессов и так далее.
4) телнет (tcping) в порт целевого хоста и постороннего хоста для сравнения. Чтобы проверить не блокирует ли вас антивирус или целевой хост.
5) помотреть логи целевого сервера. Увеличить информативность логов.
6) воткнуть хост в роутер (linuxbox) на нём собрать трафик по интересующему порту (tcpdump в файл)
7) поставить на хосте виновнике https://www.winpcap.org/ и писать трафик в файл затем посмотреть в wireshark что происходит.
8) утилиты Марка Русиновича sysinternals для анализа что там происходит с сеткой, процессы, соединения порты, ошибки работы с файлами реестром и так далее.
9) попробовать отправить файл при помощи PowerShell или любой другой утилиты вместо пайтона и curl

Стабильность возврата ошибки по идее даёт возможность найти виновника. Но "войти по RDP" имеет много отличий от запуска от имени системы или таймера. Поэтому у Вас по RDP это работает.

Comments

[Вова]

Прочитал твой ответ, прифигел, и забыл о нём на месяц.
Постфактум могу сказать следующее: проблема не в том, чтобы собрать данные, а в том, чтобы их проанализировать. Я умею пользоваться пингом и прокмоном, и даже немножко фиддлером. Но легче от этого не становится. Ибо не понятно, что и как в полученных гигабайтах потом искать. По хорошему, даже если точно знать, что в данной проблеме виноват каспер и именно он зависает, то процесс поиска "вот тут у него случился дедлок" несколько нетривиален.

[younghacker]

А как иначе?
Но собирать данные нужно в тот момент когда что-то там ломается curl начинает возвращать код 55. Нужно добиться повторения ошибки и анализировать что перестало работать.