Короткий ответ

Hang — это не «load 20». При высокой CPU SSH обычно медленный, но живой. При hang новые шеллы не открываются, D процессы не убиваются kill -9, в dmesg есть blocked for more than 120 seconds или soft lockup. До Reset снимите, что можно: ping, консоль гипервизора, SysRq w/l, последние строки journal. Иначе после перезагрузки останется только «оно зависло».

Цель: собрать признаки hang — IO, lock, NMI, oom — и выбрать действие: диск/NFS, ядро, гипервизор, а не ещё один apt upgrade вслепую.

Симптомы и как отличить

  • ping на 10.0.20.10 идёт, TCP/22 висит;
  • ping не идёт, консоль BMC тоже мертва — скорее железо/гипервизор;
  • ping не идёт, консоль жива, курсор ядра печатает hung_task — OS hang;
  • CPU 100% usr, SSH лагает, kill работает — это нагрузка CPU, не hang.
ПризнакIO hangLock/soft lockupOOMСеть
D-state на syscall read/nfsданетнетнет
hung_task на nfs_waitда
soft lockup CPU#да
Out of memoryда
нет ARPда

Возможные причины

  1. Диск не отвечает: контроллер, iSCSI, заполненный thin pool — ФС уходит в read-only или процессы липнут в D.
  2. NFS mount без soft/timeo, сервер NFS мёртв.
  3. Kernel deadlock, баг драйвера virtio/NIC.
  4. NMI watchdog: CPU крутится в ядре с отключёнными прерываниями.
  5. Буря прерываний / netfilter на шторме пакетов.
  6. Память: thrashing выглядит как hang — проверьте swap/PSI.
  7. После OOM killer подсистема оставляет locks.

Диагностика

Если SSH ещё иногда отвечает:

uptime
ps -eo pid,stat,wchan:32,cmd | awk '$2 ~ /D/'
cat /proc/meminfo | head
cat /proc/pressure/memory
cat /proc/pressure/io
dmesg -T | tail -n 80
journalctl -k -b --no-pager | tail -n 80

wchan часто io_schedule, nfs_wait_bit, call_rwsem_down_read_failed.

Состояние диска и томов:

findmnt
cat /proc/mounts
iostat -xz 1 3
df -h

Если SSH нет — консоль:

# SysRq должен быть разрешён: kernel.sysrq
cat /proc/sys/kernel/sysrq
# с консоли (не через зависший SSH):
echo w > /proc/sysrq-trigger
echo l > /proc/sysrq-trigger
dmesg | tail -n 100

w печатает blocked tasks, l — backtrace CPU. На гипервизоре это видно в serial console, если console=ttyS0 в GRUB.

NMI:

grep -i nmi /var/log/kern.log | tail
dmesg -T | grep -iE 'nmi|watchdog|lockup'

OOM vs hang: если есть Killed process, сначала OOM, hang может быть следствием.

Сеть отдельно: ss -tlnp на консоли, ip -br l. Полный сетевой отказ при живом ядре — не этот hang.

Решение

Сценарий A. NFS/iSCSI D-state

С консоли попробуйте umount -f / umount -l некорневого тома. Корень так не отмонтировать. Для корня на iSCSI — чините storage, не Ubuntu.

В fstab для необязательных NFS: bg,soft,timeo=50,_netdev — после восстановления, не в пик hang без понимания приложений (soft NFS может дать EIO в БД).

Сценарий B. Диск / thin pool

На гипервизоре проверьте datastore. В госте не запускайте fsck, пока том «клинит». После возврата I/O смотрите read-only и ext4.

Сценарий C. Soft lockup одного CPU, остальное живо

Соберите dmesg, версию uname -r, модули. Откат ядра через GRUB — валидный rollback. Не ставьте nmi_watchdog=0 как лечение (выключите датчик).

Сценарий D. Нужен reboot

Документируйте SysRq вывод. Затем:

echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger

Если и это не реагирует — Reset гипервизора. После старта сохраните journalctl -b -1 (предыдущая загрузка), если journal на диске.

Serial console и kdump: зачем до следующего hang

Без console=ttyS0,115200 в GRUB вывод SysRq на гипервизоре может не появиться, если VGA консоль зависла. Проверьте после восстановления:

grep GRUB_CMDLINE_LINUX /etc/default/grub
sudo journalctl --list-boots

kdump-tools на Ubuntu ставит crashkernel. Память crashkernel резервируется постоянно (сотни МБ). На 2 ГБ VM это само создаёт давление — не включайте kdump «на всякий» без расчёта. На 16+ ГБ — включайте, иначе каждый hang без vmcore.

Сообщения INFO: task nfsd: blocked for more than 120 seconds и blocked for more than 120 seconds у jbd2 указывают на журнал ext4, ждущий диск. Это IO hang, не userspace deadlock. Сетевой NFS hang часто в wchan=nfs_wait_bit_killable.

NMI Watchdog detected hard LOCKUP on cpu 3 при живых остальных CPU: имеет смысл taskset не поможет, нужен kernel upgrade/rollback. Зафиксируйте uname -r и список lsmod до reboot.

Не путайте systemctl isolate rescue под нагрузкой с диагностикой hang: вы ещё больше остановите I/O. Hang диагностируют наблюдением, не сменой target.

Как проверить, что проблема устранена

После возврата:

systemctl is-system-running
ps -eo stat | grep -c D
cat /proc/pressure/io
dmesg -T | grep -iE 'hung|lockup|I/O error' | tail
ssh admin@10.0.20.10 'true'

Под нагрузкой, которая воспроизводила hang, держите 15–30 минут. Один удачный SSH после reboot ничего не доказывает.

Если не помогло

  • Hang только при бэкапе: очередь диска, snapshot freeze.
  • Hang при большом трафике: irqbalance, очередь NIC, nftables с conntrack table full (nf_conntrack: table full).
  • Повторяется на одном ядре: меняйте ядро, не apt full-upgrade всего мира в пятницу.

Профилактика

  • Serial console + persistent journal на диске, не только RAM journal.
  • Мониторинг blocked процессов, iowait, PSI io, SMART/storage alerts.
  • NFS с таймаутами, согласованными с приложением.
  • kernel.sysrq хотя бы 1+bits для w/s/u/b на серверах без неконтролируемых пользователей на консоли.

FAQ

Чем hang отличается от высокой load?

При load процессы runnable, top обновляется. При hang даже top может не стартовать, D не уходит.

Можно ли echo 1 > hung_task_panic?

На отладочном стенде. В проде panic = ещё один reboot, но с vmcore если настроен kdump.

Зачем NMI watchdog?

Ловит CPU, застрявший с выключенными IRQ. Отключение скрывает баг.

Ping есть — значит ядро живо?

ICMP может отвечать драйвер/softirq при мёртвом userspace. Это всё ещё инцидент.

kdump обязателен?

Для повторяемых hang — да, иначе каждый Reset бессмыслен. Настройка kdump — отдельное окно, не в пике.