Процесс в D не завершается: как исследовать ожидание ядра

Копирование остановилось, процесс не расходует CPU и остаётся после kill -9. В ps у него состояние D. Здесь опасно повторять сигналы и сразу перезагружать сервер: можно потерять сведения о зависшем пути ввода-вывода и прервать соседние приложения. Сначала определите, чего ждёт задача.

Снять несколько наблюдений

ps -p 1234 -o pid,ppid,stat,wchan:32,etime,cmd
cat /proc/1234/wchan
cat /proc/1234/stack
cat /proc/1234/io

D обозначает непрерываемое ожидание, часто связанное с I/O. Оно может быть кратким и совершенно штатным. Проблема — задача остаётся в нём много последовательных снимков, а операция не продвигается. Сохраните время, PID, команду и повторные значения. Чтение stack обычно требует повышенных прав и зависит от настроек ядра.

wchan и стек показывают, в каком месте ядра остановилась задача. Имя функции помогает выбрать направление исследования, но само по себе не называет неисправный диск. Сопоставляйте его с открытыми файлами, точками монтирования и сообщениями ядра. Определения состояний представлены в описании proc stat.

Найти общий ресурс

ls -l /proc/1234/fd
findmnt -T /srv/data
journalctl -k --since "-15 min"

Выберите путь из работы процесса и проверьте, какая файловая система его обслуживает. Посмотрите ошибки устройства, таймауты, восстановление соединения с хранилищем и сообщения файловой системы. Если одновременно застыли несколько независимых программ на одной точке монтирования, исследование общего ресурса полезнее отладки каждой программы.

Само перечисление проблемного каталога тоже может ждать I/O. Не запускайте рекурсивный обход всего диска, если уже известно, что доступ к нему зависает. Собирайте доступные сведения из procfs, журнала и системы хранения. Для удалённого хранилища подключайте ответственного за него с точным временем и именем тома.

Почему SIGKILL не даёт мгновенного результата

Сигнал может оставаться ожидающим, пока задача находится в участке ожидания, который не допускает немедленного выхода. Когда ядро сможет продолжить выполнение, задача обработает завершение. Поэтому наличие PID после сигнала не означает, что Linux «игнорирует» администратора. Иные виды ожидания ядра могут иметь другую прерываемость; буква D — направление диагностики, а не универсальный диагноз.

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

Сопоставить две программы

Например, копировщик и генератор отчёта одновременно находятся в D. Их открытые файлы ведут в /srv/data, а findmnt показывает один и тот же том. В журнале ядра в эту минуту появились таймауты его устройства. Такая связка даёт конкретное основание исследовать путь хранения. Если же копировщик ждёт один ресурс, а отчёт другой, объединять их только по букве D преждевременно.

При нескольких снимках посмотрите изменение read_bytes и write_bytes из /proc/PID/io вместе с прогрессом приложения. Стабильные счётчики и неизменный стек поддерживают гипотезу остановившейся операции. Рост счётчиков говорит, что часть работы ещё идёт, даже если интерфейс не обновляет процент. Ни один показатель отдельно не заменяет проверку состояния хранилища.

Проверить восстановление работы

Убедитесь, что продвигается исходная операция, исчезло устойчивое D и приложение не осталось с частично завершённой работой. Проверьте целостность результата на уровне формата приложения. Снятие системного ожидания ещё не сообщает, успела ли программа записать весь экспорт или архив.

В курсе Linux и Bash для DevOps-инженеров диагностика процессов связана с дисками и журналами. Посмотрите программу: эта связка помогает превратить неподвижный PID в конкретную гипотезу о ресурсе и выбрать следующее безопасное действие.

Ещё по теме

Продолжить на практике

  • Linux и Bash для DevOps-инженеров ↗

    Linux для работы с серверами: процессы, права, systemd, сеть, диски и логи. Автоматизируйте повседневные задачи на Bash и разберите типичные сбои сервиса — от занятого порта до переполненного диска.