• Процесс намертво завис в проде? Ставим диагноз без kill -9

Процесс намертво завис в проде? Ставим диагноз без kill -9

Если сервис перестал отвечать, рука сама тянется к kill -9. Но перезапуск вслепую не решает проблему — он уничтожает контекст, и сбой повторится. Показываю, как заглянуть внутрь зависшего приложения на лету и поставить точный диагноз, не останавливая процесс.

Базовая диагностика зависания

# 1. Находим PID проблемного процесса по имени.

Код: Выделить всё

pidof my_process

# 2. Подключаемся к процессу на лету и слушаем ввод-вывод.
# -t добавит таймстампы: видно, КОГДА процесс замер.

Код: Выделить всё

sudo strace -tt -p <PID> -e trace=read,write

Расширенный мониторинг дескрипторов

# 3. Отслеживаем ВСЕ файловые операции.
# ВАЖНО: не 'open', а группа %file — современный glibc зовёт openat(), а не open(),
# поэтому одиночный 'open' почти ничего не покажет. %file ловит open, openat, stat, access.

Код: Выделить всё

sudo strace -p <PID> -e trace=read,write,%file

# Если ждёшь именно сетевую блокировку (отвалившаяся БД, зависший сокет):

Код: Выделить всё

sudo strace -p <PID> -e trace=%net

Анализ блокировки (Read Blocking)

# 4. Если вывод strace замирает на строке вида:
# read(5,
# — процесс жив, но ждёт данных в дескриптор №5.
# Отключаемся (Ctrl+C НЕ убьёт процесс) и смотрим, что это за дескриптор:

Код: Выделить всё

sudo lsof -p <PID> -a -d 5

# Быстрая альтернатива без lsof — прямо из /proc:

Код: Выделить всё

sudo ls -l /proc/<PID>/fd/5

Такой подход превращает абстрактное «оно зависло» в понятную картину: процесс может просто ждать read() из сокета из-за отвалившейся БД или недоступного пайпа, а не находиться в deadlock. Диагноз без правки кода и простоя на рестарт.

Нравится формат? Ставь

Рубрика: #шпаргалка@LinuxSkill
#Linux #Strace #Troubleshooting #DevOps #SysAdmin