Как подключиться к зависшему python скрипту?

нет

ну то есть да, можно в ssh удалённо вызвать превышение полномочий, рухнуть всё, попасть в шел, там бахнуть процесс скрипта в кору, её (его) утащить в норку и там разбирать по винтикам.

Себестоимость сего действия, это примерно 3 ваши зарплаты за всю жизнь :-)

А можно как то другим способом его отладить зависон при условии что скрипт можно перезапускать. И ждать пока он снова повиснет.

Попробуй Pyrasite.

Последний коммит от 17 года. Что то протухло.

А можно как то другим способом его отладить зависон при условии что скрипт можно перезапускать. И ждать пока он снова повиснет.

у вас что, только возможность перезапуска «черного ящика» и нет доступа к самому скрипту ? иначе можно было давно принтов-логов напихать и во всём разобраться

если нет исходников и возможности исправлять ошибку, то нахрена её лоцировать - довольно знать что ошибка есть и соотв.железяку(сервис,фреймворк) использовать нельзя

^ этот пони точно понимает, о чём говорит?

Где удалённо?

Если есть возможность подключиться по ssh, то собирается debug версия интерпретатора, под ней запускается скрипт, в момент зависания подключаемся к процессу при помощи gdb, и смотрим где и почему зависло.

Если скрипт в контейнере, то надо сгенерить свой базовый имидж на основе Python-овского, где Python будет компилироваться с отладочной информацией, и в образ должен быть включен gdb. Также надо запускать контейнер в привилегированном режиме, иначе не удастся подключиться к процессу.

Хотя, наверное, можно запускать gdb и снаружи контейнера, я не пробовал, на всякий случай сразу добавил в контейнер.

Есть паразит, как выше предложили, но у меня он тупо крашил пистон без всякого выхлопа. Вроде pygdb умеет аттач, но сам не пробовал. Ну и зависит от того как и где оно запущено. А то можно например снять снапшот всего процесса через criu, процесс грохнуть и перезапустить, а снапшот унести домой разбирать без стресса. Либо сохранить стейт вм с теми же целями. Хз, нужны какие-нибудь начальные условия что за процесс и где он крутится

Если есть возможность подключиться по ssh

тогда проще начать с изучения журналов, состояния /proc и запуска под strace - 99.9% что «скрипт» чё-то ждёт и хочет прочитать или записать. То есть для нормальной работы нехвататило какого-то чахлого файла или привелегий. С матом пополам можно разобраться

Ты не поверишь но иногда забывают убрать pdb после отладки.

Гугл говорит gcore + gdb + https://devguide.python.org/advanced-tools/gdb/ А еще gdb умеет подключаться к выполняющемуся процессу. gdb -p и вот это всё

можно

да, единственное можно отладчик ещё использовать если есть доступ к сорцам

Да, это относительно умный пони

Просто gdb ничего не даст, т.к. без отладочной информации почти невозможно понять в каком месте и из-за чего завис именно Python код.

Надо, чтобы скрипт был запущен под интерпретатором, скомпилированным с отладочной информацией.

Удаленность, если есть вход по ssh, вообще не влияет. Если входа нет то все хуже.

Можно плясать с gdb, можно просто обвешать скрипт отладочной печатью в лог и посмотреть в логе что происходит. Правда на это уйдет несколько запусков.

В приличных дистрибутивах можно поставить пакет с отладочными символами

В приличных дистрибутивах можно поставить пакет с отладочными символами

Увы, это мало помогает, когда зависает скрипт в докере. А в базовых образах Python с докер хаба он ставится не из дистра, а компилируется при билде образа.