Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
INFO: task blocked for more than 120 seconds Linux / DevOps

INFO: task blocked for more than 120 seconds — Решение зависания процессов (D-state)

Обновлено: 18.08.2026  ·  Официальная база знаний

Архитектура ошибки и симптомы сбоя

Сообщение «INFO: task blocked for more than 120 seconds (D-state hung task)» генерируется сторожевым процессом ядра khungtaskd. Ошибка указывает на то, что процесс перешел в состояние D (Uninterruptible Sleep / Беспрерывный сон) в ожидании ресурса ввода-вывода (I/O), дискового семафора или сетевого ответа NFS/iSCSI и не меняет статус свыше 120 секунд. Процессы в состоянии 'D' невозможно принудительно завершить даже сигналом kill -9.

Диагностическая таблица параметров сбоя

ПараметрЗначениеИнженерный смысл сбоя
D-State (TASK_UNINTERRUPTIBLE)Process FlagПроцесс ожидает завершения дискового или аппаратного I/O вызова в ядре.
kernel.hung_task_timeout_secs120 (default)Таймаут в секундах, после которого ядро считает задачу зависшей.
Trigger SourceDisk / SAN / NFS / LockЗадержки в дисковой подсистеме, деградация RAID, таймауты сетевых файловых систем.

Пошаговое дерево решений и сценарии траблшутинга

Сценарий 1: Локализация зависшего системного вызова

Определите, какую именно операцию ввода-вывода или блокировку ожидает зависший процесс:

# Поиск процессов в состоянии 'D':
ps aux | awk '$8 ~ /D/'

# Просмотр стека ожидания конкретного процесса (замените PID):
cat /proc/<PID>/stack
cat /proc/<PID>/wchan

Сценарий 2: Оптимизация сброса грязных страниц (Dirty Pages)

Часто зависание вызывается тем, что ядро блокирует процессы на время сброса гигабайтов кэша на медленный накопитель:

# Снижение порогов сброса буферов на диск:
sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=10

# Фиксация в /etc/sysctl.d/99-io.conf:
cat <<EOF | sudo tee -a /etc/sysctl.d/99-io.conf
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
EOF
sudo sysctl -p /etc/sysctl.d/99-io.conf

Сценарий 3: Проверка состояния сетевых ФС (NFS / CIFS / iSCSI)

Если в стеке фигурируют функции nfs_wait_bit_uninterruptible или rpc_wait_bit_killable, монтируйте NFS-шары с параметрами soft,timeo=50,retrans=2 вместо жесткого hard монтирования, чтобы исключить глухой deadlock процессов при сетевых сбоях.

Сервер баз данных или 1С зависает на дисковых операциях?
ITSTM выполнит комплексный аудит производительности дисковых массивов (iostat/fio), оптимизирует I/O шедулеры и устранит «бутылочные горлышки» в инфраструктуре.
Практический опыт инженера: При использовании SSD/NVMe дисков переключите I/O планировщик на none или mq-deadline (через /sys/block/sdX/queue/scheduler), чтобы исключить очереди ожидания в блочном слое.

Частые вопросы (FAQ)

Почему команду kill -9 нельзя применить к процессу в D-state?

В состоянии TASK_UNINTERRUPTIBLE процесс находится глубоко внутри системного вызова ядра и не обрабатывает сигналы ОС до тех пор, пока драйвер оборудования не вернет результат операции.

Приводит ли это сообщение к аварийной перезагрузке ОС?

По умолчанию нет — ядро только выводит предупреждение в dmesg. Однако если включен параметр kernel.hung_task_panic=1, система принудительно уйдет в Kernel Panic.